diff --git a/public/content/translations/cs/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/cs/developers/docs/scaling/zk-rollups/index.md index 20d2c3d3ca4..53c7a37289b 100644 --- a/public/content/translations/cs/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/cs/developers/docs/scaling/zk-rollups/index.md @@ -1,52 +1,52 @@ --- -title: Rollupy s nulovým přístupem -description: Úvod do rollupů s nulovou znalostí – řešení pro škálování, které používá komunita Etherea. +title: "Rollupy s nulovou znalostí" +description: "Úvod do rollupů s nulovou znalostí – řešení pro škálování, které používá komunita Etherea." lang: cs --- -Rollupy s nulovou znalostí (ZK-rollupy) jsou [škálovací řešení](/developers/docs/scaling/) vrstvy 2, která zvyšují propustnost na Ethereum Mainnetu tím, že přesouvají výpočty a ukládání stavu mimo řetězec. ZK-rollupy mohou zpracovat tisíce transakcí v jednom balíku a poté na Mainnetu zveřejní pouze minimální souhrnná data. Tato souhrnná data definují změny, které by měly být provedeny ve stavu Etherea, a obsahují kryptografický důkaz o správnosti těchto změn. +Zero-knowledge rollupy (ZK-rollupy) jsou [řešení pro škálování](/developers/docs/scaling/) vrstvy 2, která zvyšují propustnost na hlavní síti Ethereum přesunutím výpočtů a ukládání stavů mimo řetězec. ZK-rollupy mohou zpracovat tisíce transakcí v jednom balíku a poté na Mainnetu zveřejní pouze minimální souhrnná data. Tato souhrnná data definují změny, které by měly být provedeny ve stavu Etherea, a obsahují kryptografický důkaz o správnosti těchto změn. ## Předpoklady {#prerequisites} -Měli byste si přečíst a porozumět naší stránce o [škálování Etherea](/developers/docs/scaling/) a [vrstvě 2](/layer-2). +Měli byste si přečíst a pochopit naši stránku o [škálování Etherea](/developers/docs/scaling/) a [vrstvě 2](/layer-2). ## Co jsou rollupy s nulovou znalostí? {#what-are-zk-rollups} -**Rollupy s nulovou znalostí (ZK-rollupy)** seskupují (nebo „rolují“) transakce do balíků, které jsou exekuovány mimo řetězec. Off-chain výpočty snižují množství dat, která musí být zveřejněna na blockchainu. Operátoři ZK-rollupů předkládají souhrn změn potřebných k reprezentaci všech transakcí v balíku místo toho, aby odesílali každou transakci jednotlivě. Také vytvářejí [důkazy o platnosti](/glossary/#validity-proof), které prokazují správnost těchto změn. +**Zero-knowledge rollupy (ZK-rollupy)** seskupují (nebo „rolují“) transakce do balíků, které jsou exekuovány mimo blockchain. Výpočty mimo blockchain snižují množství dat, která musí být zveřejněna na blockchainu. Operátoři ZK-rollupů předkládají souhrn změn potřebných k reprezentaci všech transakcí v balíku místo toho, aby odesílali každou transakci jednotlivě. Také vytvářejí [důkazy platnosti](/glossary/#validity-proof), aby prokázaly správnost svých změn. -Stav ZK-rollupu je udržován smart kontraktem nasazeným na síti Etherea. Pro aktualizaci stavu musí síťové uzly ZK-rollupu předložit důkaz o platnosti k ověření. Jak bylo zmíněno, důkaz o platnosti je kryptografickou zárukou, že změna stavu navržená rollupem je skutečně výsledkem exekuce daného balíku transakcí. To znamená, že ZK-rollupy potřebují k finalizaci transakcí na Ethereu poskytnout pouze důkazy o platnosti namísto zveřejnění všech transakčních dat na řetězci, jako to dělají [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/). +Stav ZK-rollupu je udržován smart kontraktem nasazeným na síti Etherea. Pro aktualizaci stavu musí síťové uzly ZK-rollupu předložit důkaz o platnosti k ověření. Jak bylo zmíněno, důkaz o platnosti je kryptografickou zárukou, že změna stavu navržená rollupem je skutečně výsledkem exekuce daného balíku transakcí. To znamená, že ZK-rollupy potřebují k finalizaci transakcí na Ethereu poskytnout pouze důkazy platnosti namísto zveřejnění všech transakčních dat na blockchainu, jako to dělají [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/). Při přesunu prostředků ze ZK-rollupu na Ethereum nedochází ke zpožděním, protože transakce výstupu jsou provedeny ihned po ověření důkazu o platnosti kontraktem ZK-rollupu. Naopak výběr prostředků z optimistických rollupů podléhá zpoždění, aby měl kdokoli možnost napadnout výstupní transakci [důkazem podvodu](/glossary/#fraud-proof). -ZK-rollupy zapisují transakce na Ethereum jako `calldata`. `calldata` je místo, kde jsou uložena data, která jsou zahrnuta v externích voláních funkcí smart kontraktů. Informace v `calldata` jsou publikovány na blockchainu, což umožňuje komukoli nezávisle rekonstruovat stav rollupu. ZK-rollupy používají kompresní techniky ke snížení objemu transakčních dat – například účty jsou reprezentovány indexem namísto adresy, což ušetří 28 bajtů dat. Publikování dat na řetězec je pro rollupy velkým nákladem, takže komprese dat může snížit poplatky uživatelů. +ZK-rollupy zapisují transakce na Ethereum jako `calldata`. `calldata` je místo, kde jsou uložena data, která jsou zahrnuta v externích voláních funkcí chytrých kontraktů. Informace v `calldata` jsou publikovány na blockchainu, což umožňuje komukoli nezávisle rekonstruovat stav rollupu. ZK-rollupy používají kompresní techniky ke snížení objemu transakčních dat – například účty jsou reprezentovány indexem namísto adresy, což ušetří 28 bajtů dat. Publikování dat na blockchainu je pro rollupy velkým nákladem, takže komprese dat může snížit poplatky uživatelů. -## Jak ZK-rollupy interagují s Ethereem? {#zk-rollups-and-ethereum} +## Jak ZK-rollupy interagují s Ethereem? ZK-rollupy a Ethereum {#zk-rollups-and-ethereum} -Řetězec ZK-rollupu je off-chain protokol, který funguje na vrcholu blockchainu Etherea a je řízen on-chain smart kontrakty na Ethereu. ZK-rollupy provádějí transakce mimo Mainnet, ale pravidelně odesílají balíky transakcí z off-chain na on-chain kontrakt rollupu. Tento záznam transakcí je neměnný, podobně jako blockchain Etherea, a tvoří řetězec ZK-rollupu. +Řetězec ZK-rollupu je off-chain protokol, který funguje na vrcholu blockchainu Ethereum a je řízen on-chain chytrými kontrakty na Ethereu. ZK-rollupy provádějí transakce mimo hlavní síť, ale pravidelně odesílají off-chain balíčky transakcí do on-chain rollup kontraktu. Tento záznam transakcí je neměnný, podobně jako blockchain Etherea, a tvoří řetězec ZK-rollupu. Základní architektura ZK-rollupu se skládá z následujících komponent: -1. **On-chain kontrakty**: Jak již bylo zmíněno, ZK-rollup protokol je řízen smart kontrakty běžícími na Ethereu. To zahrnuje hlavní kontrakt, který ukládá bloky rollupu, sleduje vklady a monitoruje aktualizace stavu. Další on-chain kontrakt (ověřovací kontrakt) ověřuje důkazy s nulovou znalostí předložené producenty bloků. Ethereum tak slouží jako základní vrstva nebo „vrstva 1“ pro ZK-rollup. +1. **On-chain kontrakty**: Jak již bylo zmíněno, ZK-rollup protokol je řízen chytrými kontrakty běžícími na Ethereu. To zahrnuje hlavní kontrakt, který ukládá bloky rollupu, sleduje vklady a monitoruje aktualizace stavu. Další on-chain kontrakt (ověřovací kontrakt) ověřuje důkazy s nulovou znalostí předložené producenty bloků. Ethereum tak slouží jako základní vrstva nebo „vrstva 1“ pro ZK-rollup. -2. **Off-chain virtuální stroj (VM)**: Zatímco ZK-rollup protokol existuje na Ethereu, provádění transakcí a ukládání stavu probíhá na samostatném virtuálním stroji nezávislém na [EVM](/developers/docs/evm/). Tento off-chain VM je prostředí pro provádění transakcí na ZK-rollupu a slouží jako sekundární vrstva nebo „vrstva 2“ pro ZK-rollup protokol. Důkazy o platnosti ověřené na Ethereum Mainnetu zaručují správnost přechodů stavu v off-chain VM. +2. **Off-chain virtuální stroj (VM)**: Zatímco ZK-rollup protokol existuje na Ethereu, provádění transakcí a ukládání stavu probíhá na samostatném virtuálním stroji nezávislém na [EVM](/developers/docs/evm/). Tento off-chain VM je prostředí pro provádění transakcí na ZK-rollupu a slouží jako sekundární vrstva nebo „vrstva 2“ pro ZK-rollup protokol. Důkazy platnosti ověřené na hlavní síti Ethereum zaručují správnost přechodů stavu v off-chain VM. -ZK-rollupy jsou „hybridní škálovací řešení“ – off-chain protokoly, které fungují nezávisle, ale odvozují bezpečnost od Etherea. Konkrétně síť Etherea vynucuje platnost aktualizací stavu na ZK-rollupu a zaručuje dostupnost dat za každou aktualizací stavu rollupu. Výsledkem je, že ZK-rollupy jsou podstatně bezpečnější než čistě off-chain škálovací řešení, jako jsou [postranní řetězce](/developers/docs/scaling/sidechains/), které jsou odpovědné za své bezpečnostní vlastnosti, nebo [validia](/developers/docs/scaling/validium/), která také ověřují transakce na Ethereu pomocí důkazů o platnosti, ale ukládají transakční data jinde. +ZK-rollupy jsou „hybridní řešení pro škálování“ – off-chain protokoly, které fungují nezávisle, ale odvozují bezpečnost od Etherea. Konkrétně síť Etherea vynucuje platnost aktualizací stavu na ZK-rollupu a zaručuje dostupnost dat za každou aktualizací stavu rollupu. V důsledku toho jsou ZK-rollupy podstatně bezpečnější než čistě off-chain řešení pro škálování, jako jsou [sidechainy](/developers/docs/scaling/sidechains/), které jsou odpovědné za své bezpečnostní vlastnosti, nebo [validia](/developers/docs/scaling/validium/), která také ověřují transakce na Ethereu pomocí důkazů platnosti, ale ukládají transakční data jinde. Rollupy s nulovou znalostí se spoléhají na hlavní protokol Etherea z následujících důvodů: ### Dostupnost dat {#data-availability} -ZK-rollupy publikují stavová data pro každou transakci zpracovanou mimo řetězec na Ethereu. S těmito daty je možné, aby jednotlivci nebo firmy reprodukovali stav rollupu a sami si ověřili řetězec. Ethereum zpřístupňuje tato data všem účastníkům sítě jako `calldata`. +ZK-rollupy publikují stavová data pro každou transakci zpracovanou mimo blockchain na Ethereu. S těmito daty je možné, aby jednotlivci nebo firmy reprodukovali stav rollupu a sami si ověřili řetězec. Ethereum zpřístupňuje tato data všem účastníkům sítě jako `calldata`. -ZK-rollupy nepotřebují zveřejňovat mnoho transakčních dat on-chain, protože důkazy o platnosti již ověřují autenticitu změn stavu. Nicméně ukládání dat on-chain je stále důležité, protože umožňuje nezávislé ověření stavu řetězce vrstvy 2 bez nutnosti důvěry, což zase umožňuje komukoli odesílat balíky transakcí a zabraňuje škodlivým operátorům v cenzurování nebo zmrazení řetězce. +ZK-rollupy nepotřebují zveřejňovat mnoho transakčních dat on-chain, protože důkazy platnosti již ověřují autenticitu změn stavu. Nicméně ukládání dat on-chain je stále důležité, protože umožňuje nezávislé ověření stavu řetězce vrstvy 2 bez nutnosti povolení, což zase umožňuje komukoli odesílat balíky transakcí a zabraňuje škodlivým operátorům v cenzurování nebo zmrazení řetězce. On-chain data jsou nezbytná pro to, aby mohli uživatelé interagovat s rollupem. Bez přístupu k datům stavu uživatelé nemohou dotazovat zůstatek svého účtu nebo iniciovat transakce (např. výběry), které závisí na informacích o stavu. -### Finálnost transakcí {#transaction-finality} +### Finalita transakce {#transaction-finality} Ethereum funguje jako vypořádací vrstva pro ZK-rollupy: Transakce vrstvy 2 jsou finalizovány pouze tehdy, pokud L1 kontrakt přijme důkaz o platnosti. To eliminuje riziko, že by podvodní operátoři mohli řetězec zkompromitovat (např. ukrást prostředky rollupu), protože každá transakce musí být schválena na Mainnetu. Ethereum také zaručuje, že uživatelské operace nemohou být po jejich finalizaci na L1 zrušeny. -### Odolnost proti cenzuře {#censorship-resistance} +### Odolnost vůči cenzuře {#censorship-resistance} Většina ZK-rollupů používá „superuzel“ (operátora) k provádění transakcí, vytváření balíků a odesílání bloků na vrstvu 1. I když to zajišťuje efektivitu, zvyšuje to riziko cenzury: Podvodní operátoři ZK-rollupu mohou cenzurovat uživatele tím, že odmítnou zahrnout jejich transakce do balíků. @@ -58,29 +58,29 @@ Jako bezpečnostní opatření umožňují ZK-rollupy uživatelům zasílat tran Uživatelé v ZK-rollupu podepisují transakce a zasílají je operátorům L2 ke zpracování a zahrnutí do dalšího balíku. V některých případech je operátor centralizovaný subjekt, nazývaný sekvencer, který provádí transakce, agreguje je do balíků a odesílá na vrstvu 1. Sekvencer v tomto systému je jediným subjektem, který má povoleno vytvářet bloky vrstvy 2 a přidávat transakce rollupu do kontraktu ZK-rollupu. -Jiné ZK-rollupy mohou rotovat roli operátora pomocí sady validátorů [proof of stake](/developers/docs/consensus-mechanisms/pos/). Potenciální operátoři vkládají prostředky do kontraktu rollupu, přičemž velikost každého vkladu ovlivňuje šance stakera na výběr pro vytvoření dalšího balíku rollupu. Podíl operátora může být penalizován snížením zástavy, pokud jedná podvodně, což ho motivuje k tomu, aby odesílal platné bloky. +Jiné ZK-rollupy mohou rotovat roli operátora pomocí sady validátorů s [důkazem podílem](/developers/docs/consensus-mechanisms/pos/). Potenciální operátoři vkládají prostředky do kontraktu rollupu, přičemž velikost každého vkladu ovlivňuje šance stakera na výběr pro vytvoření dalšího balíku rollupu. Podíl operátora může být penalizován snížením zástavy, pokud jedná podvodně, což ho motivuje k tomu, aby odesílal platné bloky. #### Jak ZK-rollupy publikují transakční data na Ethereu {#how-zk-rollups-publish-transaction-data-on-ethereum} -Jak jsme už vysvětlili, transakční data jsou publikována na Ethereu jako `calldata`. `calldata` je datová oblast ve smart kontraktu, která slouží k předávání argumentů do funkce a chová se podobně jako [paměť](/developers/docs/smart-contracts/anatomy/#memory). Zatímco oblast `calldata` není uložena jako součást stavu Etherea, přetrvává na řetězci jako součást [historických logů](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) řetězce Etherea. `calldata` neovlivňuje stav Etherea, což z ní činí levný způsob ukládání dat na řetězci. +Jak jsme už vysvětlili, transakční data jsou publikována na Ethereu jako `calldata`. `calldata` je datová oblast v chytrém kontraktu, která slouží k předávání argumentů funkci a chová se podobně jako [paměť](/developers/docs/smart-contracts/anatomy/#memory). `calldata` se neukládají jako součást stavu Etherea, ale přetrvávají na blockchainu jako součást [historických protokolů](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) řetězce Ethereum. `calldata` neovlivňuje stav Etherea, což z ní činí levný způsob ukládání dat na blockchainu. -Klíčové slovo `calldata` často identifikuje metodu smart kontraktu, kterou transakce volá, a obsahuje vstupy do metody ve formě libovolné posloupnosti bajtů. ZK-rollupy používají `calldata` k publikování komprimovaných transakčních dat na řetězec; operátor rollupu jednoduše přidá nový balík tím, že zavolá požadovanou funkci v kontraktu rollupu a předá komprimovaná data jako argumenty funkce. To pomáhá snižovat náklady uživatelů, protože velká část poplatků za rollupy jde na ukládání transakčních dat na řetězci. +Klíčové slovo `calldata` často identifikuje metodu chytrého kontraktu, kterou transakce volá, a obsahuje vstupy do metody ve formě libovolné posloupnosti bajtů. ZK-rollupy používají `calldata` k publikování komprimovaných transakčních dat na blockchainu; operátor rollupu jednoduše přidá nový balík tím, že zavolá požadovanou funkci v kontraktu rollupu a předá komprimovaná data jako argumenty funkce. To pomáhá snižovat náklady uživatelům, protože velká část poplatků za rollupy jde na ukládání transakčních dat na blockchainu. ### Závazky stavu {#state-commitments} -Stav ZK-rollupu, který zahrnuje účty a zůstatky vrstvy 2, je reprezentován jako [Merkle tree](/whitepaper/#merkle-trees). Kryptografický hash kořene Merkle tree (Merkle kořen) je uložen v on-chain kontraktu, což umožňuje protokolu rollupu sledovat změny ve stavu ZK-rollupu. +Stav ZK-rollupu, který zahrnuje účty a zůstatky vrstvy 2, je reprezentován jako [Merkle tree](/whitepaper/#merkle-trees). Kryptografický haš kořene Merkle tree (kořen Merkle) je uložen v on-chain kontraktu, což umožňuje protokolu rollupu sledovat změny ve stavu ZK-rollupu. Rollup přechází do nového stavu po provedení nové sady transakcí. Operátor, který inicioval přechod stavu, musí vypočítat nový kořen stavu a předložit ho on-chain kontraktu. Pokud je důkaz o platnosti spojený s balíkem ověřen ověřovacím kontraktem, nový Merkle kořen se stává kanonickým kořenem stavu ZK-rollupu. -Kromě výpočtu kořenů stavu operátor ZK-rollupu také vytváří kořen balíku – kořen Merkle tree zahrnujícího všechny transakce v balíku. Když je předložen nový balík, kontrakt rollupu ukládá kořen balíku, což umožňuje uživatelům prokázat, že transakce (např. žádost o výběr) byla zahrnuta do balíku. Uživatelé budou muset poskytnout podrobnosti o transakci, kořen balíku a [Merkle důkaz](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) prokazující cestu vedoucí k zahrnutí. +Kromě výpočtu kořenů stavu operátor ZK-rollupu také vytváří kořen balíku – kořen Merkle tree zahrnujícího všechny transakce v balíku. Když je předložen nový balík, kontrakt rollupu ukládá kořen balíku, což umožňuje uživatelům prokázat, že transakce (např. žádost o výběr) byla zahrnuta do balíku. Uživatelé budou muset poskytnout podrobnosti o transakci, kořen balíku a [Merkle proof](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) prokazující cestu vedoucí k zahrnutí. ### Důkazy platnosti {#validity-proofs} -Nový kořen stavu, který operátor ZK-rollupu předloží L1 kontraktu, je výsledkem aktualizací stavu rollupu. Řekněme, že Alice pošle Bobovi 10 tokenů, operátor jednoduše sníží zůstatek Alice o 10 a zvýší zůstatek Boba o 10. Operátor pak zahešuje aktualizovaná data účtu, znovu vytvoří Merkle tree rollupu a předloží nový Merkle kořen on-chain kontraktu. +Nový kořen stavu, který operátor ZK-rollupu předloží L1 kontraktu, je výsledkem aktualizací stavu rollupu. Řekněme, že Alice pošle Bobovi 10 tokenů, operátor jednoduše sníží zůstatek Alice o 10 a zvýší zůstatek Boba o 10. Operátor pak zahešuje aktualizovaná data účtu, znovu vytvoří Merkle tree rollupu a předloží nový kořen Merkle on-chain kontraktu. Ale kontrakt rollupu automaticky nepřijme navrhovaný závazek stavu, dokud operátor neprokáže, že nový Merkle kořen je výsledkem správných aktualizací stavu rollupu. Operátor ZK-rollupu to provede vytvořením důkazu platnosti, což je stručný kryptografický závazek ověřující správnost seskupených transakcí. -Důkazy platnosti umožňují stranám prokázat správnost tvrzení, aniž by odhalily samotné tvrzení – proto se také nazývají důkazy s nulovou znalostí. ZK-rollupy používají důkazy o platnosti k potvrzení správnosti off-chain přechodů stavu, aniž by bylo nutné znovu provádět transakce na Ethereu. Tyto důkazy mohou mít podobu [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) nebo [ZK-STARK](https://eprint.iacr.org/2018/046) (Zero-Knowledge Scalable Transparent Argument of Knowledge). +Důkazy platnosti umožňují stranám prokázat správnost tvrzení, aniž by odhalily samotné tvrzení – proto se také nazývají důkazy s nulovou znalostí. ZK-rollupy používají důkazy platnosti k potvrzení správnosti off-chain přechodů stavu, aniž by bylo nutné znovu provádět transakce na Ethereu. Tyto důkazy mohou mít podobu [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) nebo [ZK-STARK](https://eprint.iacr.org/2018/046) (Zero-Knowledge Scalable Transparent Argument of Knowledge). Oba typy důkazů, SNARKy a STARKy, pomáhají potvrdit integritu off-chain výpočtů v ZK-rollupech, ačkoli každý typ důkazu má své charakteristické rysy. @@ -88,7 +88,7 @@ Oba typy důkazů, SNARKy a STARKy, pomáhají potvrdit integritu off-chain výp Aby protokol ZK-SNARK fungoval, je nutné vytvořit společný referenční řetězec (Common Reference String, CRS): CRS poskytuje veřejné parametry pro dokazování a ověřování důkazů o platnosti. Bezpečnost systému dokazování závisí na nastavení CRS; pokud by se informace použité k vytvoření veřejných parametrů dostaly do rukou podvodníků, mohli by být schopni generovat falešné důkazy platnosti. -Některé ZK-rollupy se pokoušejí tento problém vyřešit pomocí [ceremoniálu více stran (multi-party computation ceremony, MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), který zahrnuje důvěryhodné jednotlivce při generování veřejných parametrů pro ZK-SNARK okruh. Každá strana přispívá určitou náhodností (nazývanou „toxický odpad“) k vytvoření CRS, kterou musí okamžitě zničit. +Některé ZK-rollupy se pokoušejí tento problém vyřešit pomocí [ceremoniálu více stran (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), který zahrnuje důvěryhodné jednotlivce při generování veřejných parametrů pro ZK-SNARK okruh. Každá strana přispívá určitou náhodností (nazývanou „toxický odpad“) k vytvoření CRS, kterou musí okamžitě zničit. Důvěryhodné nastavení se používá, protože zvyšuje bezpečnost nastavení CRS. V případě, že byť pouze jeden čestný účastník zničí svůj vstup, je bezpečnost ZK-SNARK systému zaručena. Tento přístup však vyžaduje důvěru, že zapojení jedinci skutečně vymažou svou náhodnost a nepodkopou bezpečnostní záruky systému. @@ -100,11 +100,11 @@ Stejně jako ZK-SNARKy, ZK-STARKy prokazují platnost off-chain výpočtů, ani ZK-STARKy jsou „transparentní“, protože mohou fungovat bez nastavení společného referenčního řetězce (CRS), které vyžaduje důvěru. Místo toho se ZK-STARKy spoléhají na veřejně ověřitelnou náhodnost k nastavení parametrů pro generování a ověřování důkazů. -ZK-STARKy také poskytují větší škálovatelnost, protože čas potřebný k prokázání a ověření důkazů o platnosti roste _kvazilineárně_ ve vztahu ke složitosti podkladového výpočtu. U ZK-SNARKů se čas potřebný k prokázání a ověření důkazů škáluje _lineárně_ ve vztahu k velikosti podkladového výpočtu. To znamená, že ZK-STARKy vyžadují méně času než ZK-SNARKy pro prokazování a ověřování, když jsou zahrnuty velké objemy dat, což je činí užitečnými pro aplikace s vysokým objemem transakcí. +ZK-STARKy také poskytují větší škálovatelnost, protože čas potřebný k prokázání a ověření důkazů platnosti roste _kvazilineárně_ ve vztahu ke složitosti podkladového výpočtu. U ZK-SNARKů se čas potřebný k prokázání a ověření důkazů škáluje _lineárně_ ve vztahu k velikosti podkladového výpočtu. To znamená, že ZK-STARKy vyžadují méně času než ZK-SNARKy pro prokazování a ověřování, když jsou zahrnuty velké objemy dat, což je činí užitečnými pro aplikace s vysokým objemem transakcí. ZK-STARKy jsou také bezpečné vůči kvantovým počítačům, zatímco se obecně věří, že kryptografie na eliptických křivkách (Elliptic Curve Cryptography, ECC) používaná v ZK-SNARK řešeních je náchylná k útokům kvantových počítačů. Nevýhodou ZK-STARKů je, že produkují větší velikosti důkazů, což je dražší na ověřování na Ethereu. -#### Jak fungují důkazy o platnosti na ZK-rollupech? {#validity-proofs-in-zk-rollups} +#### Jak fungují důkazy o platnosti na ZK-rollupech? Důkazy platnosti v ZK-rollupech {#validity-proofs-in-zk-rollups} ##### Generování důkazů @@ -136,11 +136,11 @@ ZK-ověřovací okruh iteruje celým balíkem transakcí, ověřuje sekvenci akt Po ověření správnosti aktualizací stavu ověřovacím okruhem podá operátor L2 vypočítaný důkaz o platnosti ověřovacímu kontraktu na L1. Ověřovací okruh kontraktu ověřuje platnost důkazu a také kontroluje veřejné vstupy, které jsou součástí důkazu: -- **Představový kořen**: Starý kořen stavu ZK-rollupu (tj. před provedením seskupených transakcí), který odráží poslední známý platný stav řetězce L2. +- **Kořen předchozího stavu**: Starý kořen stavu ZK-rollupu (tj. před provedením seskupených transakcí), který odráží poslední známý platný stav řetězce L2. -- **Po-stavový kořen**: Nový kořen stavu ZK-rollupu (tj. po provedení seskupených transakcí), který odráží nejnovější stav řetězce L2. Po-stavový kořen je finální kořen odvozený po aplikaci aktualizací stavu v ověřovacím okruhu. +- **Kořen následujícího stavu**: Nový kořen stavu ZK-rollupu (tj. po provedení seskupených transakcí), který odráží nejnovější stav řetězce L2. Po-stavový kořen je finální kořen odvozený po aplikaci aktualizací stavu v ověřovacím okruhu. -- **Kořen balíku**: Merkle kořen balíku, odvozený _merklováním_ transakcí v balíku a hašováním kořene stromu. +- **Kořen balíku**: Kořen Merkle balíku, odvozený _merklováním_ transakcí v balíku a hašováním kořene stromu. - **Transakční vstupy**: Data spojená s transakcemi, které jsou součástí podaného balíku. @@ -166,9 +166,9 @@ Rollup kontrakt zahašuje transakční data, ověří, zda kořen balíku existu ## ZK-rollupy a kompatibilita s EVM {#zk-rollups-and-evm-compatibility} -Na rozdíl od optimistických rollupů nejsou ZK-rollupy snadno kompatibilní s [Virtuálním strojem Etherea (EVM)](/developers/docs/evm/). Ověřování obecného výpočtu EVM v okruzích je složitější a náročnější na zdroje než ověřování jednoduchých výpočtů (jako je dříve popsaný převod tokenů). +Na rozdíl od optimistických rollupů nejsou ZK-rollupy snadno kompatibilní s [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). Ověřování obecného výpočtu EVM v okruzích je složitější a náročnější na zdroje než ověřování jednoduchých výpočtů (jako je dříve popsaný převod tokenů). -[Pokroky v technologii nulové znalosti](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) však znovu probouzí zájem o zabalení výpočtů EVM do důkazů s nulovou znalostí. Tyto snahy směřují k vytvoření implementace EVM s nulovou znalostí (zkEVM), která by mohla efektivně ověřovat správnost provádění programů. zkEVM znovu vytváří stávající opkódy EVM pro dokazování a nebo ověřování v okruzích, což umožňuje exekuci smart kontraktů. +[Pokroky v technologii nulové znalosti](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) však znovu probouzejí zájem o zabalení výpočtů EVM do důkazů s nulovou znalostí. Tyto snahy směřují k vytvoření implementace EVM s nulovou znalostí (zkEVM), která by mohla efektivně ověřovat správnost provádění programů. zkEVM znovu vytváří stávající opkódy EVM pro dokazování a nebo ověřování v okruzích, což umožňuje exekuci smart kontraktů. Stejně jako EVM přechází zkEVM mezi stavy po provedení výpočtu na základě některých vstupů. Rozdíl je v tom, že zkEVM také vytváří důkazy s nulovou znalostí pro ověření správnosti každého kroku v exekuci programu. Důkazy o platnosti by mohly ověřovat správnost operací, které ovlivňují stav VM (paměť, zásobník, úložiště) a samotný výpočet (tj. zda operace zavolala správné opkódy a provedla je správně). @@ -180,19 +180,19 @@ Kolik uživatelé platí za transakce na ZK-rollupech závisí na poplatku za pa 1. **Zápis stavu**: Náklad na zápis do stavu Etherea (tj. podání transakce na blockchainu Etherea) je pevně daný. ZK-rollupy tento náklad snižují tím, že seskupují transakce a rozdělují pevné náklady mezi více uživatelů. -2. **Publikování dat**: ZK-rollupy publikují stavová data pro každou transakci na Ethereu jako `calldata`. Náklady na `calldata` jsou aktuálně řízeny [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), který stanovuje náklady 16 jednotek paliva za bajt, který není nulový, a 4 jednotky paliva za nulový bajt `calldata`. Cena zaplacená za každou transakci je ovlivněna množstvím `calldata`, které je potřeba zveřejnit. +2. **Publikování dat**: ZK-rollupy publikují stavová data pro každou transakci na Ethereu jako `calldata`. Náklady na `calldata` jsou aktuálně řízeny [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), který stanovuje náklady 16 jednotek paliva za nenulové bajty a 4 jednotky paliva za nulové bajty `calldata`. Cena zaplacená za každou transakci je ovlivněna množstvím `calldata`, které je pro ni potřeba zveřejnit na blockchainu. -3. **Poplatky operátorů L2**: Toto je částka vyplacená operátorovi rollupu jako kompenzace za výpočetní náklady spojené se zpracováním transakcí, podobně jako [„poplatky za prioritu transakce (spropitné)“](/developers/docs/gas/#how-are-gas-fees-calculated) na Ethereum Mainnetu. +3. **Poplatky operátora L2**: Toto je částka vyplacená operátorovi rollupu jako kompenzace za výpočetní náklady spojené se zpracováním transakcí, podobně jako [transakční "poplatky za prioritu (spropitné)"](/developers/docs/gas/#how-are-gas-fees-calculated) na hlavní síti Ethereum. -4. **Generování a ověřování důkazů**: Operátoři ZK-rollupu musí produkovat důkazy o platnosti pro transakční balíky, což je náročné na zdroje. Ověřování důkazů s nulovou znalostí na Mainnetu stojí další palivo (asi 500 000 jednotek paliva). +4. **Generování a ověřování důkazů**: Operátoři ZK-rollupu musí produkovat důkazy platnosti pro transakční balíky, což je náročné na zdroje. Ověřování důkazů s nulovou znalostí na Mainnetu stojí další palivo (asi 500 000 jednotek paliva). -Kromě seskupování transakcí snižují ZK-rollupy poplatky pro uživatele kompresí transakčních dat. Můžete se [podívat na aktuální přehled nákladů](https://l2fees.info/) na používání Ethereum ZK-rollupů. +Kromě seskupování transakcí snižují ZK-rollupy poplatky pro uživatele kompresí transakčních dat. Můžete se [podívat na přehled v reálném čase](https://l2fees.info/) o tom, kolik stojí používání ZK-rollupů na Ethereu. ## Jak ZK-rollupy škálují Ethereum? {#scaling-ethereum-with-zk-rollups} -### Komprese dat transakcí {#transaction-data-compression} +### Komprese transakčních dat {#transaction-data-compression} -ZK-rollupy zvyšují propustnost na základní vrstvě Etherea tím, že přesouvají výpočty mimo řetězec, ale skutečný impuls pro škálování přichází s kompresí transakčních dat. [Velikost bloku](/developers/docs/blocks/#block-size) Etherea omezuje množství dat, které může každý blok pojmout, a tím i počet transakcí zpracovaných na blok. Kompresí dat souvisejících s transakcemi ZK-rollupy významně zvyšují počet transakcí zpracovaných v jednom bloku. +ZK-rollupy zvyšují propustnost na základní vrstvě Etherea tím, že přesouvají výpočty mimo řetězec, ale skutečný impuls pro škálování přichází s kompresí transakčních dat. [Velikost bloku](/developers/docs/blocks/#block-size) na Ethereu omezuje množství dat, které může každý blok pojmout, a tím i počet transakcí zpracovaných na blok. Kompresí dat souvisejících s transakcemi ZK-rollupy významně zvyšují počet transakcí zpracovaných v jednom bloku. ZK-rollupy mohou komprimovat transakční data lépe než optimistické rollupy, protože nemusí zveřejňovat všechna data potřebná k ověření každé transakce. Musí zveřejnit pouze minimální data potřebná k obnovení nejnovějšího stavu účtů a zůstatků na rollupu. @@ -206,49 +206,52 @@ Rekurzivní důkazy však umožňují finalizovat několik bloků jedním důkaz ### Výhody a nevýhody ZK-rollupů {#zk-rollups-pros-and-cons} -| Plusy | Minusy | -| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Důkazy o platnosti zajišťují správnost transakcí mimo řetězec a zabraňují operátorům provádět neplatné přechody stavu. | Náklady spojené s výpočtem a ověřováním důkazů o platnosti jsou značné a mohou zvýšit poplatky pro uživatele rollupu. | -| Nabízejí rychlejší finálnost transakcí, protože aktualizace stavu jsou schváleny, jakmile jsou důkazy o platnosti ověřeny na L1. | Vývoj ZK-rollupů kompatibilních s EVM je obtížný kvůli složitosti technologie nulové znalosti. | -| Spoléhají se na kryptografické mechanismy pro bezpečnost, u kterých není důvěra podmínkou používání, nikoli na čestnost incentivovaných aktérů, jako je tomu u [optimistických rollupů](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | Produkování důkazů platnosti vyžaduje specializovaný hardware, což může podpořit centralizovanou kontrolu řetězce několika stranami. | -| Ukládají data potřebná k obnovení stavu mimo řetězec na L1, což zaručuje bezpečnost, odolnost vůči cenzuře a decentralizaci. | Centralizovaní operátoři (sekvencery) mohou ovlivňovat pořadí transakcí. | -| Uživatelé profitují z vyšší efektivity kapitálu a mohou vybírat prostředky z L2 bez zpoždění. | Požadavky na hardware mohou snížit počet účastníků, kteří mohou vynutit posun řetězce, čímž se zvyšuje riziko, že podvodní operátoři zmrazí stav rollupu a budou cenzurovat uživatele. | -| Nespadají pod předpoklady o živosti a uživatelé nemusí validovat řetězec, aby chránili své prostředky. | Některé ověřovací systémy (např. ZK-SNARK) vyžadují důvěryhodné nastavení, které, pokud je špatně zvládnuto, by mohlo potenciálně ohrozit bezpečnostní model ZK-rollupu. | -| Lepší komprese dat může pomoci snížit náklady na publikování `calldata` na Ethereu a minimalizovat poplatky uživatelů za používání rollupu. | | +| Plusy | Minusy | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Důkazy platnosti zajišťují správnost transakcí mimo řetězec a zabraňují operátorům provádět neplatné přechody stavu. | Náklady spojené s výpočtem a ověřováním důkazů o platnosti jsou značné a mohou zvýšit poplatky pro uživatele rollupu. | +| Nabízejí rychlejší finálnost transakcí, protože aktualizace stavu jsou schváleny, jakmile jsou důkazy o platnosti ověřeny na L1. | Vývoj ZK-rollupů kompatibilních s EVM je obtížný kvůli složitosti technologie nulové znalosti. | +| Spoléhá na kryptografické mechanismy bez potřeby důvěry pro zabezpečení, nikoli na poctivost motivovaných aktérů jako u [optimistických rollupů](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons). | Produkování důkazů platnosti vyžaduje specializovaný hardware, což může podpořit centralizovanou kontrolu řetězce několika stranami. | +| Ukládá data potřebná k obnovení stavu mimo řetězec na L1, což zaručuje bezpečnost, odolnost vůči cenzuře a decentralizaci. | Centralizovaní operátoři (sekvencery) mohou ovlivňovat pořadí transakcí. | +| Uživatelé profitují z vyšší efektivity kapitálu a mohou vybírat prostředky z L2 bez zpoždění. | Požadavky na hardware mohou snížit počet účastníků, kteří mohou vynutit posun řetězce, čímž se zvyšuje riziko, že podvodní operátoři zmrazí stav rollupu a budou cenzurovat uživatele. | +| Nespadají pod předpoklady o živosti a uživatelé nemusí validovat řetězec, aby chránili své prostředky. | Některé ověřovací systémy (např. ZK-SNARK) vyžadují důvěryhodné nastavení, které, pokud je špatně zvládnuto, by mohlo potenciálně ohrozit bezpečnostní model ZK-rollupu. | +| Lepší komprese dat může pomoci snížit náklady na publikování `calldata` na Ethereu a minimalizovat poplatky uživatelů za používání rollupu. | | -### Vizualizace ZK-rollupů {#zk-video} +### Vizuální vysvětlení ZK-rollupů {#zk-video} Podívejte se na vysvětlení ZK-rollupů od Finematics: - -## Kdo pracuje na zkEVM? {#zkevm-projects} +## Kdo pracuje na zkEVM? Projekty zkEVM {#zkevm-projects} Projekty pracující na zkEVM zahrnují: -- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** – _zkEVM je projekt financovaný Ethereum Foundation, jehož cílem je vyvinout ZK-rollup kompatibilní s EVM a mechanismus pro generování důkazů platnosti pro bloky Etherea._ +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _zkEVM je projekt financovaný Nadací Ethereum, jehož cílem je vyvinout ZK-rollup kompatibilní s EVM a mechanismus pro generování důkazů platnosti pro bloky Etherea._ + +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _je decentralizovaný ZK-rollup na hlavní síti Ethereum pracující na virtuálním stroji Ethereum s nulovou znalostí (zkEVM), který transparentně provádí transakce Ethereum, včetně chytrých kontraktů s ověřením pomocí důkazů s nulovou znalostí._ -- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** – _je decentralizovaný ZK Rollup na Ethereum Mainnetu, který pracuje na Virtuálním stroji Etherea s nulovou znalostí (zkEVM), provádí Ethereum transakce transparentním způsobem, včetně smart kontraktů s ověřením pomocí důkazů s nulovou znalostí._ +- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll je technologicky zaměřená společnost, která pracuje na vybudování nativního řešení zkEVM vrstvy 2 pro Ethereum._ -- **[Scroll](https://scroll.io/blog/zkEVM)** – _Scroll je technologicky zaměřená společnost, která pracuje na vybudování nativního zkEVM řešení vrstvy 2 pro Ethereum._ +- **[Taiko](https://taiko.xyz)** - _Taiko je decentralizovaný, s Ethereem ekvivalentní ZK-rollup ([Typ 1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ -- **[Taiko](https://taiko.xyz)** – _Taiko je decentralizovaný, Ethereum-ekvivalentní ZK-rollup ([typ 1 ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ +- **[ZKsync](https://docs.zksync.io/)** - _ZKsync Era je ZK-rollup kompatibilní s EVM vyvinutý společností Matter Labs, poháněný vlastním zkEVM._ -- **[ZKsync](https://docs.zksync.io/)** – _ZKsync Era je ZK Rollup kompatibilní s EVM vyvinutý Matter Labs, poháněný vlastním zkEVM._ +- **[Starknet](https://starkware.co/starknet/)** - _StarkNet je řešení pro škálování vrstvy 2 kompatibilní s EVM, vyvinuté společností StarkWare._ -- **[Starknet](https://starkware.co/starknet/)** – _StarkNet je škálovací řešení vrstvy 2 kompatibilní s EVM vyvinuté společností StarkWare._ +- **[Morph](https://www.morphl2.io/)** - _Morph je hybridní rollupové řešení pro škálování, které využívá důkaz s nulovou znalostí k řešení problému se stavem vrstvy 2._ -- **[Morph](https://www.morphl2.io/)** – _Morph je hybridní škálovací řešení rollupu, které využívá důkazy s nulovou znalostí k řešení problému se stavem vrstvy 2._ +- **[Linea](https://linea.build)** - _Linea je s Ethereem ekvivalentní zkEVM vrstvy 2, vytvořený společností Consensys, plně v souladu s ekosystémem Ethereum._ -## Další čtení o ZK-rollupech {#further-reading-on-zk-rollups} +## Další četba o ZK-rollupech {#further-reading-on-zk-rollups} - [Co jsou rollupy s nulovou znalostí?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) - [Co jsou rollupy s nulovou znalostí?](https://alchemy.com/blog/zero-knowledge-rollups) -- [STARKy vs SNARKy](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) -- [Co je zkEVM?](https://www.alchemy.com/overviews/zkevm) -- [Typy ZK-EVM: Ethereum-ekvivalentní, EVM-ekvivalentní, Type 1, Type 4 a další kryptické pojmy](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [Praktický průvodce rollupy na Ethereu](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [STARKy vs. SNARKy](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [Co je to zkEVM?](https://www.alchemy.com/overviews/zkevm) +- [Typy ZK-EVM: ekvivalentní Ethereu, ekvivalentní EVM, typ 1, typ 4 a další záhadná módní slova](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) - [Úvod do zkEVM](https://hackmd.io/@yezhang/S1_KMMbGt) -- [Zdroje awesome-zkEVM](https://github.com/LuozhuZhang/awesome-zkevm) -- [ZK-SNARKY pod pokličkou](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [Co jsou ZK-EVM L2?](https://linea.mirror.xyz/qD18IaQ4BROn_Y40EBMTUTdJHYghUtdECscSWyMvm8M) +- [Úžasné zdroje o zkEVM](https://github.com/LuozhuZhang/awesome-zkevm) +- [ZK-SNARKy pod pokličkou](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) - [Jak jsou SNARKy možné?](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/cs/developers/docs/smart-contracts/anatomy/index.md index 56c3d72b80d..6049029c3d9 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/anatomy/index.md @@ -1,6 +1,6 @@ --- -title: Anatomie chytrých kontraktů -description: Podrobný pohled na anatomii chytrého kontaktu – funkce, údaje a proměnné. +title: "Anatomie chytrých kontraktů" +description: "Podrobný pohled na anatomii chytrého kontaktu – funkce, údaje a proměnné." lang: cs --- @@ -8,32 +8,32 @@ Chytrý kontrakt je program běžící na adrese na Ethereu. Skládá se z dat ## Předpoklady {#prerequisites} -Nejprve se ujistěte, že jste si přečetli o [chytrých kontraktech](/developers/docs/smart-contracts/). Tento dokument předpokládá, že již znáte programovací jazyky, jako je JavaScript nebo Python. +Ujistěte se, že jste si nejprve přečetli o [chytrých kontraktech](/developers/docs/smart-contracts/). Tento dokument předpokládá, že již znáte programovací jazyky, jako je JavaScript nebo Python. ## Data {#data} -Veškeré údaje o kontraktu musí být přiřazeny k lokaci: buď do `storage`, nebo do `memory`. Úprava storage v chytrém kontraktu je nákladná, takže je třeba zvážit, kde by měla být vaše data uložena. +Jakákoli data kontraktu musí být přiřazena k umístění: buď do `storage` nebo `memory`. Úprava storage v chytrém kontraktu je nákladná, takže je třeba zvážit, kde by měla být vaše data uložena. ### Úložiště {#storage} Trvalá data se označují jako storage a jsou reprezentována stavovými proměnnými. Tyto hodnoty se trvale uloží na blockchain. Datový typ je třeba deklarovat, aby kontrakt mohl při kompilaci sledovat, kolik potřebuje na blockchainu úložiště. ```solidity -// Solidity example +// Příklad v Solidity contract SimpleStorage { - uint storedData; // State variable + uint storedData; // Stavová proměnná // ... } ``` ```python -# Vyper example +# Příklad ve Vyperu storedData: int128 ``` -Pokud jste již programovali v objektově orientovaných jazycích, většinu typů pravděpodobně znáte. Nicméně `address` by pro vás měla být novinkou, pokud s vývojem na Ethereu teprve začínáte. +Pokud jste již programovali v objektově orientovaných jazycích, většinu typů pravděpodobně znáte. Nicméně `address` by pro vás mělo být novinkou, pokud s vývojem na Ethereu teprve začínáte. -Datový typ `address` může obsahovat Ethereum adresu, která odpovídá 20 bajtům nebo 160 bitům. Návratová hodnota je v hexadecimálním zápisu začínajícím 0x. +Datový typ `address` může obsahovat adresu Ethereum, která odpovídá 20 bajtům nebo 160 bitům. Návratová hodnota je v hexadecimálním zápisu začínajícím 0x. Mezi další datové typy patří: @@ -49,14 +49,14 @@ Mezi další datové typy patří: Další vysvětlení najdete v těchto dokumentech: -- [Datové typy ve Vyper](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types) -- [Datové typy v Solidity](https://solidity.readthedocs.io/en/latest/types.html#value-types) +- [Zobrazit typy Vyperu](https://docs.vyperlang.org/en/v0.1.0-beta.6/types.html#value-types) +- [Zobrazit typy Solidity](https://docs.soliditylang.org/en/latest/types.html#value-types) -### Memory {#memory} +### Paměť {#memory} Hodnoty, které jsou uloženy pouze po dobu provádění funkce kontraktu, se nazývají paměťové proměnné. Protože nejsou trvale uloženy na blockchainu, je jejich používání mnohem levnější. -Více informací o tom, jak EVM ukládá data (Storage, Memory a Stack), najdete v [dokumentech Solidity](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack). +Dozvíte se více o tom, jak EVM ukládá data (úložiště, paměť a zásobník) v [dokumentaci Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#storage-memory-and-the-stack). ### Proměnné prostředí {#environment-variables} @@ -64,10 +64,10 @@ Kromě proměnných, které definujete v kontraktu, existují i speciální glob Příklady: -| **Objekt** | **Stavová proměnná** | **Popis** | -| ----------------- | -------------------- | ------------------------------------ | -| `block.timestamp` | uint256 | Časové razítko aktuální epochy bloku | -| `msg.sender` | address (adresa) | Odesílatel zprávy (aktuální volání) | +| **Vlastnost** | **Stavová proměnná** | **Popis** | +| ----------------- | -------------------- | ------------------------------------------------------ | +| `block.timestamp` | uint256 | Časové razítko aktuální epochy bloku | +| `msg.sender` | adresa | Odesílatel zprávy (aktuální volání) | ## Funkce {#functions} @@ -75,37 +75,37 @@ Nejjednodušeji řečeno, funkce mohou získávat informace nebo nastavovat info Existují dva typy volání funkcí: -- `internal` – nevytvářejí EVM volání +- `internal` – nevytvářejí volání EVM - K interním funkcím a stavovým proměnným lze přistupovat pouze interně (tj. v rámci aktuálního kontraktu nebo kontraktů z něho odvozených). -- `external` – vytvářejí EVM volání - - Externí funkce jsou součástí rozhraní kontraktu, což znamená, že je lze volat z jiných kontraktů a prostřednictvím transakcí. Externí funkce `f` nelze volat interně (tzn. `f()` nefunguje, ale `this.f()` ano). +- `external` – vytvářejí volání EVM + - Externí funkce jsou součástí rozhraní kontraktu, což znamená, že je lze volat z jiných kontraktů a prostřednictvím transakcí. Externí funkci `f` nelze volat interně (tzn. `f()` nefunguje, ale `this.f()` ano). -Tyto funkce mohou být také `public` nebo `private`. +Mohou být také `public` nebo `private`. -- Funkce `public` lze volat interně z kontraktu nebo externě prostřednictvím zpráv -- Funkce `private` jsou viditelné pouze pro kontrakt, ve kterém jsou definovány, a ne v odvozených kontraktech +- `public` funkce lze volat interně z kontraktu nebo externě prostřednictvím zpráv +- `private` funkce jsou viditelné pouze pro kontrakt, ve kterém jsou definovány, a ne v odvozených kontraktech Funkce i stavové proměnné mohou být veřejné nebo soukromé. Zde je funkce pro aktualizaci stavové proměnné v kontraktu: ```solidity -// Solidity example +// Příklad v Solidity function update_name(string value) public { dapp_name = value; } ``` -- Parametr `value` typu `string` je předán funkci: `update_name` -- Je deklarována jako `public`, což znamená, že k ní má kdokoli přístup -- Není deklarována jako `view`, takže kdokoli může změnit stav kontraktu +- Parametr `value` typu `string` je předán do funkce `update_name`. +- Je deklarována jako `public`, což znamená, že k ní má kdokoli přístup. +- Není deklarována jako `view`, takže může měnit stav kontraktu. -### View funkce {#view-functions} +### Funkce `view` {#view-functions} Tyto funkce slibují, že nebudou měnit stav dat kontraktu. Běžným příkladem jsou „getter“ funkce – můžete je použít například k získání zůstatku uživatele. ```solidity -// Solidity example +// Příklad v Solidity function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } @@ -123,33 +123,33 @@ def readName() -> string: Co se považuje jako změna stavu: 1. Zápis do stavových proměnných. -2. [Odesílání událostí](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events). -3. [Vytváření jiných kontraktů](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts). -4. Používání `selfdestruct`. +2. [Vysílání událostí](https://docs.soliditylang.org/en/v0.7.0/contracts.html#events). +3. [Vytváření dalších kontraktů](https://docs.soliditylang.org/en/v0.7.0/control-structures.html#creating-contracts). +4. Použití `selfdestruct`. 5. Posílání etheru pomocí volání. 6. Volání jakékoli funkce, která není označena jako `view` nebo `pure`. 7. Používání nízkoúrovňových volání. 8. Používání inline assembly, která obsahuje určité operační kódy. -### Funkce konstruktor {#constructor-functions} +### Konstruktory {#constructor-functions} -Funkce `konstruktor` se provedou pouze jednou při prvním nasazení kontraktu. Podobně jako `konstruktory` v mnoha programovacích jazycích založených na třídách, tyto funkce často inicializují stavové proměnné na zadané hodnoty. +Funkce `constructor` se provedou pouze jednou, při prvním nasazení kontraktu. Podobně jako `constructor` v mnoha programovacích jazycích založených na třídách, tyto funkce často inicializují stavové proměnné na zadané hodnoty. ```solidity -// Solidity example -// Initializes the contract's data, setting the `owner` -// to the address of the contract creator. +// Příklad v Solidity +// Inicializuje data kontraktu, nastaví `owner` +// na adresu tvůrce kontraktu. constructor() public { - // All smart contracts rely on external transactions to trigger its functions. - // `msg` is a global variable that includes relevant data on the given transaction, - // such as the address of the sender and the ETH value included in the transaction. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // Všechny chytré kontrakty spoléhají na externí transakce, které spouští jejich funkce. + // `msg` je globální proměnná, která obsahuje relevantní údaje o dané transakci, + // jako je adresa odesílatele a hodnota ETH obsažená v transakci. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } ``` ```python -# Vyper example +# Příklad ve Vyperu @external def __init__(_beneficiary: address, _bidding_time: uint256): @@ -180,26 +180,26 @@ Vaše funkce potřebuje: pragma solidity >=0.4.0 <=0.6.0; contract ExampleDapp { - string dapp_name; // state variable + string dapp_name; // stavová proměnná - // Called when the contract is deployed and initializes the value + // Volá se při nasazení kontraktu a inicializuje hodnotu constructor() public { dapp_name = "My Example dapp"; } - // Get Function + // Funkce pro získání (Get) function read_name() public view returns(string) { return dapp_name; } - // Set Function + // Funkce pro nastavení (Set) function update_name(string value) public { dapp_name = value; } } ``` -Kompletní kontrakt může vypadat následovně. Zde funkce `konstruktor` poskytuje počáteční hodnotu proměnné `dapp_name`. +Kompletní kontrakt může vypadat následovně. Zde funkce `constructor` poskytuje počáteční hodnotu proměnné `dapp_name`. ## Události a záznamy {#events-and-logs} @@ -207,39 +207,39 @@ Události umožňují vašemu chytrému kontraktu komunikovat s vaším frontend ## Příklady s poznámkami {#annotated-examples} -Zde jsou příklady napsané v Solidity. Pokud si chcete s kódem pohrát, můžete tak udělat v [Remixu](http://remix.ethereum.org). +Zde jsou příklady napsané v Solidity. Pokud si chcete s kódem pohrát, můžete s ním interagovat v [Remixu](http://remix.ethereum.org). -### Ahoj světe {#hello-world} +### Hello world {#hello-world} ```solidity -// Specifies the version of Solidity, using semantic versioning. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +// 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.5.10; -// Defines a contract named `HelloWorld`. -// A contract is a collection of functions and data (its state). -// Once deployed, a contract resides at a specific address on the Ethereum blockchain. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +// Definuje kontrakt s názvem `HelloWorld`. +// Kontrakt je soubor funkcí a dat (jeho stav). +// Po nasazení se kontrakt nachází na specifické adrese na ethereovém blockchainu. +// Více informací: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html contract HelloWorld { - // Declares a state variable `message` of type `string`. - // State variables are variables whose values are permanently stored in contract storage. - // The keyword `public` makes variables accessible from outside a contract - // and creates a function that other contracts or clients can call to access the value. + // 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 jiné kontrakty nebo klienti volat pro přístup k hodnotě. string public message; - // Similar to many class-based object-oriented languages, a constructor is - // a special function that is only executed upon contract creation. - // Constructors are used to initialize the contract's data. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + // Podobně jako v mnoha objektově orientovaných jazycích založených na třídá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) public { - // Accepts a string argument `initMessage` and sets the value - // into the contract's `message` storage variable). + // Přijímá argument `initMessage` typu string a nastavuje hodnotu + // do úložné proměnné kontraktu `message`. message = initMessage; } - // A public function that accepts a string argument - // and updates the `message` storage variable. + // Veřejná funkce, která přijímá argument typu string + // a aktualizuje úložnou proměnnou `message`. function update(string memory newMessage) public { message = newMessage; } @@ -252,58 +252,58 @@ contract HelloWorld { pragma solidity ^0.5.10; contract Token { - // An `address` is comparable to an email address - it's used to identify an account on Ethereum. - // Addresses can represent a smart contract or an external (user) accounts. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + // Typ `address` je srovnatelný s e-mailovou adresou – používá se k identifikaci účtu na Ethereu. + // Adresy mohou představovat chytrý kontrakt nebo externí (uživatelské) účty. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/types.html#address address public owner; - // A `mapping` is essentially a hash table data structure. - // This `mapping` assigns an unsigned integer (the token balance) to an address (the token holder). - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + // `mapping` je v podstatě datová struktura hašovací tabulky. + // Tento `mapping` přiřazuje celé číslo bez znaménka (zůstatek tokenů) k adrese (držiteli tokenů). + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types mapping (address => uint) public balances; - // Events allow for logging of activity on the blockchain. - // Ethereum clients can listen for events in order to react to contract state changes. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + // Události umožňují zaznamenávat aktivitu na blockchainu. + // Klienti Etherea mohou naslouchat událostem, aby mohli reagovat na změny stavu kontraktu. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events event Transfer(address from, address to, uint amount); - // Initializes the contract's data, setting the `owner` - // to the address of the contract creator. + // Inicializuje data kontraktu, nastaví `owner` + // na adresu tvůrce kontraktu. constructor() public { - // All smart contracts rely on external transactions to trigger its functions. - // `msg` is a global variable that includes relevant data on the given transaction, - // such as the address of the sender and the ETH value included in the transaction. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + // Všechny chytré kontrakty spoléhají na externí transakce, které spouští jejich funkce. + // `msg` je globální proměnná, která obsahuje relevantní údaje o dané transakci, + // jako je adresa odesílatele a hodnota ETH obsažená v transakci. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties owner = msg.sender; } - // Creates an amount of new tokens and sends them to an address. + // Vytvoří množství nových tokenů a pošle je na adresu. function mint(address receiver, uint amount) public { - // `require` is a control structure used to enforce certain conditions. - // If a `require` statement evaluates to `false`, an exception is triggered, - // which reverts all changes made to the state during the current call. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // `require` je řídicí struktura používaná k vynucení určitých podmínek. + // Pokud se příkaz `require` vyhodnotí jako `false`, dojde k výjimce, + // která vrátí všechny změny stavu provedené během aktuálního volání. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // Only the contract owner can call this function + // Tuto funkci může volat pouze vlastník kontraktu require(msg.sender == owner, "You are not the owner."); - // Enforces a maximum amount of tokens + // Vynucuje maximální množství tokenů require(amount < 1e60, "Maximum issuance exceeded"); - // Increases the balance of `receiver` by `amount` + // Zvýší zůstatek `receiver` o `amount` balances[receiver] += amount; } - // Sends an amount of existing tokens from any caller to an address. + // Odesílá množství existujících tokenů od libovolného volajícího na adresu. function transfer(address receiver, uint amount) public { - // The sender must have enough tokens to send + // Odesílatel musí mít dostatek tokenů k odeslání require(amount <= balances[msg.sender], "Insufficient balance."); - // Adjusts token balances of the two addresses + // Upravuje zůstatky tokenů na obou adresách balances[msg.sender] -= amount; balances[receiver] += amount; - // Emits the event defined earlier + // Vysílá dříve definovanou událost emit Transfer(msg.sender, receiver, amount); } } @@ -314,74 +314,74 @@ contract Token { ```solidity pragma solidity ^0.5.10; -// Imports symbols from other files into the current contract. -// In this case, a series of helper contracts from OpenZeppelin. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files +// Importuje symboly z jiných souborů do aktuálního kontraktu. +// V tomto případě se jedná o sérii pomocných kontraktů z OpenZeppelin. +// Více informací: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; -// The `is` keyword is used to inherit functions and keywords from external contracts. -// In this case, `CryptoPizza` inherits from the `IERC721` and `ERC165` contracts. -// Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +// Klíčové slovo `is` se používá k dědění funkcí a klíčových slov z externích kontraktů. +// V tomto případě `CryptoPizza` dědí z kontraktů `IERC721` a `ERC165`. +// Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance contract CryptoPizza is IERC721, ERC165 { - // Uses OpenZeppelin's SafeMath library to perform arithmetic operations safely. - // Learn more: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + // Používá knihovnu SafeMath od OpenZeppelin k bezpečnému provádění aritmetických operací. + // Více informací: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath using SafeMath for uint256; - // Constant state variables in Solidity are similar to other languages - // but you must assign from an expression which is constant at compile time. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + // Konstantní stavové proměnné v Solidity jsou podobné jako v jiných jazycích + // ale musíte je přiřadit z výrazu, který je konstantní v době kompilace. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables uint256 constant dnaDigits = 10; uint256 constant dnaModulus = 10 ** dnaDigits; bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; - // Struct types let you define your own type - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + // Typy `struct` umožňují definovat vlastní typ + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs struct Pizza { string name; uint256 dna; } - // Creates an empty array of Pizza structs + // Vytvoří prázdné pole struktur Pizza Pizza[] public pizzas; - // Mapping from pizza ID to its owner's address + // Mapování z ID pizzy na adresu jejího vlastníka mapping(uint256 => address) public pizzaToOwner; - // Mapping from owner's address to number of owned token + // Mapování z adresy vlastníka na počet vlastněných tokenů mapping(address => uint256) public ownerPizzaCount; - // Mapping from token ID to approved address + // Mapování z ID tokenu na schválenou adresu mapping(uint256 => address) pizzaApprovals; - // You can nest mappings, this example maps owner to operator approvals + // Mapování lze vnořovat, tento příklad mapuje vlastníka na schválení operátora mapping(address => mapping(address => bool)) private operatorApprovals; - // Internal function to create a random Pizza from string (name) and DNA + // Interní funkce pro vytvoření náhodné pizzy z řetězce (jméno) a DNA function _createPizza(string memory _name, uint256 _dna) - // The `internal` keyword means this function is only visible - // within this contract and contracts that derive this contract - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + // Klíčové slovo `internal` znamená, že tato funkce je viditelná pouze + // v rámci tohoto kontraktu a kontraktů, které z něj dědí + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters internal - // `isUnique` is a function modifier that checks if the pizza already exists - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + // `isUnique` je modifikátor funkce, který kontroluje, zda pizza již existuje + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers isUnique(_name, _dna) { - // Adds Pizza to array of Pizzas and get id + // Přidá pizzu do pole pizz a získá ID uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); - // Checks that Pizza owner is the same as current user - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + // Kontroluje, zda je vlastník pizzy stejný jako aktuální uživatel + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - // note that address(0) is the zero address, - // indicating that pizza[id] is not yet allocated to a particular user. + // Všimněte si, že address(0) je nulová adresa, + // což znamená, že pizza[id] ještě není přidělena konkrétnímu uživateli. assert(pizzaToOwner[id] == address(0)); - // Maps the Pizza to the owner + // Mapuje pizzu na vlastníka pizzaToOwner[id] = msg.sender; ownerPizzaCount[msg.sender] = SafeMath.add( ownerPizzaCount[msg.sender], @@ -389,38 +389,38 @@ contract CryptoPizza is IERC721, ERC165 { ); } - // Creates a random Pizza from string (name) + // Vytvoří náhodnou pizzu z řetězce (jméno) function createRandomPizza(string memory _name) public { uint256 randDna = generateRandomDna(_name, msg.sender); _createPizza(_name, randDna); } - // Generates random DNA from string (name) and address of the owner (creator) + // Generuje náhodné DNA z řetězce (jméno) a adresy vlastníka (tvůrce) function generateRandomDna(string memory _str, address _owner) public - // Functions marked as `pure` promise not to read from or modify the state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + // Funkce označené jako `pure` slibují, že nebudou číst ani upravovat stav + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions pure returns (uint256) { - // Generates random uint from string (name) + address (owner) + // Generuje náhodné uint z řetězce (jméno) + adresy (vlastník) uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + uint256(_owner); rand = rand % dnaModulus; return rand; } - // Returns array of Pizzas found by owner + // Vrací pole pizz nalezených podle vlastníka function getPizzasByOwner(address _owner) public - // Functions marked as `view` promise not to modify state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + // Funkce označené jako `view` slibují, že nebudou upravovat stav + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions view returns (uint256[] memory) { - // Uses the `memory` storage location to store values only for the - // lifecycle of this function call. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + // Používá `memory` jako umístění úložiště pro uložení hodnot pouze pro + // životní cyklus tohoto volání funkce. + // Více informací: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); uint256 counter = 0; for (uint256 i = 0; i < pizzas.length; i++) { @@ -432,7 +432,7 @@ contract CryptoPizza is IERC721, ERC165 { return result; } - // Transfers Pizza and ownership to other address + // Převádí pizzu a vlastnictví na jinou adresu function transferFrom(address _from, address _to, uint256 _pizzaId) public { require(_from != address(0) && _to != address(0), "Invalid address."); require(_exists(_pizzaId), "Pizza does not exist."); @@ -443,17 +443,17 @@ contract CryptoPizza is IERC721, ERC165 { ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); pizzaToOwner[_pizzaId] = _to; - // Emits event defined in the imported IERC721 contract + // Vysílá událost definovanou v importovaném kontraktu IERC721 emit Transfer(_from, _to, _pizzaId); _clearApproval(_to, _pizzaId); } /** - * Safely transfers the ownership of a given token ID to another address - * If the target address is a contract, it must implement `onERC721Received`, - * which is called upon a safe transfer, and return the magic value + * Bezpečně převede vlastnictví daného ID tokenu na jinou adresu + * Pokud je cílová adresa kontrakt, musí implementovat `onERC721Received`, + * která se volá při bezpečném převodu a vrátí magickou hodnotu * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * jinak se převod vrátí zpět. */ function safeTransferFrom(address from, address to, uint256 pizzaId) public @@ -463,11 +463,11 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Safely transfers the ownership of a given token ID to another address - * If the target address is a contract, it must implement `onERC721Received`, - * which is called upon a safe transfer, and return the magic value + * Bezpečně převede vlastnictví daného ID tokenu na jinou adresu + * Pokud je cílová adresa kontrakt, musí implementovat `onERC721Received`, + * která se volá při bezpečném převodu a vrátí magickou hodnotu * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * otherwise, the transfer is reverted. + * jinak se převod vrátí zpět. */ function safeTransferFrom( address from, @@ -480,8 +480,8 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Internal function to invoke `onERC721Received` on a target address - * The call is not executed if the target address is not a contract + * Interní funkce pro vyvolání `onERC721Received` na cílové adrese + * Volání se neprovede, pokud cílová adresa není kontrakt */ function _checkOnERC721Received( address from, @@ -502,9 +502,9 @@ contract CryptoPizza is IERC721, ERC165 { return (retval == _ERC721_RECEIVED); } - // Burns a Pizza - destroys Token completely - // The `external` function modifier means this function is - // part of the contract interface and other contracts can call it + // Spálí pizzu - kompletně zničí token + // Modifikátor funkce `external` znamená, že tato funkce je + // součástí rozhraní kontraktu a mohou ji volat jiné kontrakty function burn(uint256 _pizzaId) external { require(msg.sender != address(0), "Invalid address."); require(_exists(_pizzaId), "Pizza does not exist."); @@ -517,26 +517,26 @@ contract CryptoPizza is IERC721, ERC165 { pizzaToOwner[_pizzaId] = address(0); } - // Returns count of Pizzas by address + // Vrací počet pizz podle adresy function balanceOf(address _owner) public view returns (uint256 _balance) { return ownerPizzaCount[_owner]; } - // Returns owner of the Pizza found by id + // Vrací vlastníka pizzy nalezeného podle ID function ownerOf(uint256 _pizzaId) public view returns (address _owner) { address owner = pizzaToOwner[_pizzaId]; require(owner != address(0), "Invalid Pizza ID."); return owner; } - // Approves other address to transfer ownership of Pizza + // Schvaluje jinou adresu k převodu vlastnictví pizzy function approve(address _to, uint256 _pizzaId) public { require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); pizzaApprovals[_pizzaId] = _to; emit Approval(msg.sender, _to, _pizzaId); } - // Returns approved address for specific Pizza + // Vrací schválenou adresu pro konkrétní pizzu function getApproved(uint256 _pizzaId) public view @@ -547,8 +547,8 @@ contract CryptoPizza is IERC721, ERC165 { } /** - * Private function to clear current approval of a given token ID - * Reverts if the given address is not indeed the owner of the token + * Soukromá funkce pro zrušení aktuálního schválení daného ID tokenu + * Vrátí se zpět, pokud daná adresa není skutečně vlastníkem tokenu */ function _clearApproval(address owner, uint256 _pizzaId) private { require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); @@ -559,8 +559,8 @@ contract CryptoPizza is IERC721, ERC165 { } /* - * Sets or unsets the approval of a given operator - * An operator is allowed to transfer all tokens of the sender on their behalf + * Nastavuje nebo ruší schválení daného operátora + * Operátor má povoleno převádět všechny tokeny odesílatele jeho jménem */ function setApprovalForAll(address to, bool approved) public { require(to != msg.sender, "Cannot approve own address"); @@ -568,7 +568,7 @@ contract CryptoPizza is IERC721, ERC165 { emit ApprovalForAll(msg.sender, to, approved); } - // Tells whether an operator is approved by a given owner + // Sdělí, zda je operátor schválen daným vlastníkem function isApprovedForAll(address owner, address operator) public view @@ -577,27 +577,27 @@ contract CryptoPizza is IERC721, ERC165 { return operatorApprovals[owner][operator]; } - // Takes ownership of Pizza - only for approved users + // Přebírá vlastnictví pizzy - pouze pro schválené uživatele function takeOwnership(uint256 _pizzaId) public { require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); address owner = this.ownerOf(_pizzaId); this.transferFrom(owner, msg.sender, _pizzaId); } - // Checks if Pizza exists + // Kontroluje, zda pizza existuje function _exists(uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; return owner != address(0); } - // Checks if address is owner or is approved to transfer Pizza + // Kontroluje, zda je adresa vlastníkem nebo je schválena k převodu pizzy function _isApprovedOrOwner(address spender, uint256 pizzaId) internal view returns (bool) { address owner = pizzaToOwner[pizzaId]; - // Disable solium check because of + // Vypnout kontrolu solium kvůli // https://github.com/duaraghav8/Solium/issues/175 // solium-disable-next-line operator-whitespace return (spender == owner || @@ -605,7 +605,7 @@ contract CryptoPizza is IERC721, ERC165 { this.isApprovedForAll(owner, spender)); } - // Check if Pizza is unique and doesn't exist yet + // Zkontrolujte, zda je pizza jedinečná a ještě neexistuje modifier isUnique(string memory _name, uint256 _dna) { bool result = true; for (uint256 i = 0; i < pizzas.length; i++) { @@ -621,15 +621,15 @@ contract CryptoPizza is IERC721, ERC165 { _; } - // Returns whether the target address is a contract + // Vrací, zda je cílová adresa kontrakt function isContract(address account) internal view returns (bool) { uint256 size; - // Currently there is no better way to check if there is a contract in an address - // than to check the size of the code at that address. - // See https://ethereum.stackexchange.com/a/14016/36603 - // for more details about how this works. - // TODO Check this again before the Serenity release, because all addresses will be - // contracts then. + // V současné době neexistuje lepší způsob, jak zkontrolovat, zda je na adrese kontrakt + // než zkontrolovat velikost kódu na dané adrese. + // Viz https://ethereum.stackexchange.com/a/14016/36603 + // pro více detailů o tom, jak to funguje. + // TODO Zkontrolovat znovu před vydáním Serenity, protože všechny adresy budou + // poté kontrakty. // solium-disable-next-line security/no-inline-assembly assembly { size := extcodesize(account) @@ -639,20 +639,20 @@ contract CryptoPizza is IERC721, ERC165 { } ``` -## Další informace {#further-reading} +## Další čtení {#further-reading} Kompletní přehled chytrých kontraktů najdete v dokumentaci Solidity a Vyper: -- [Solidity](https://solidity.readthedocs.io/) -- [Vyper](https://vyper.readthedocs.io/) +- [Solidity](https://docs.soliditylang.org/) +- [Vyper](https://docs.vyperlang.org/en/stable/) ## Související témata {#related-topics} - [Chytré kontrakty](/developers/docs/smart-contracts/) -- [Virtuální stroj Etherea](/developers/docs/evm/) +- [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) ## Související návody {#related-tutorials} -- [Zmenšování kontraktů pro boj s limitem velikosti kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– několik praktických tipů pro zmenšení velikosti vašeho chytrého kontraktu._ -- [Zaznamenávání dat z chytrých kontraktů pomocí událostí](/developers/tutorials/logging-events-smart-contracts/) _– úvod do událostí chytrých kontraktů a jak je můžete použít k zaznamenávání dat._ -- [Interagujte s dalšími kontrakty ze Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak nasadit chytrý kontrakt z existujícího kontraktu a interagovat s ním._ +- [Zmenšování kontraktů pro boj s limitem velikosti kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Několik praktických tipů pro zmenšení velikosti vašeho chytrého kontraktu._ +- [Zaznamenávání dat z chytrých kontraktů pomocí událostí](/developers/tutorials/logging-events-smart-contracts/) _– Úvod do událostí chytrých kontraktů a jak je můžete použít k zaznamenávání dat._ +- [Interakce s dalšími kontrakty ze Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Jak nasadit chytrý kontrakt z existujícího kontraktu a interagovat s ním._ diff --git a/public/content/translations/cs/developers/docs/smart-contracts/compiling/index.md b/public/content/translations/cs/developers/docs/smart-contracts/compiling/index.md index 6453d8e4347..7669de7c1bf 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/compiling/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/compiling/index.md @@ -1,6 +1,6 @@ --- -title: Zpracování chytrých smluv -description: Vysvětlení, proč je třeba kompilovat chytré kontrakty a co kompilace vlastně dělá. +title: "Kompilace chytrých kontraktů" +description: "Vysvětlení, proč je třeba kompilovat chytré kontrakty a co kompilace vlastně dělá." lang: cs incomplete: true --- @@ -9,7 +9,7 @@ Kontrakt musíte zkompilovat tak, aby mu webová aplikace a virtuální stroj Et ## Předpoklady {#prerequisites} -Možná vám pomůže, když si před čtením o kompilaci přečtete náš úvod do [chytrých kontraktů](/developers/docs/smart-contracts/) a [virtuálního stroje Etherea](/developers/docs/evm/). +Možná vám pomůže, když si před čtením o kompilaci přečtete náš úvod do [chytrých kontraktů](/developers/docs/smart-contracts/) a [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). ## EVM {#the-evm} @@ -20,14 +20,14 @@ pragma solidity 0.4.24; contract Greeter { - function greet() public constant returns (string) { + function greet() public view returns (string memory) { return "Hello"; } } ``` -**tohle** +**v toto** ``` PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 @@ -272,11 +272,11 @@ Níže je uvedeno ABI pro kontrakt na tokeny ERC-20. ERC-20 je token, se kterým ] ``` -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [ABI specifikace](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ +- [Specifikace ABI](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ ## Související témata {#related-topics} - [JavaScriptové klientské knihovny](/developers/docs/apis/javascript/) -- [Virtuální stroj Etherea](/developers/docs/evm/) +- [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/composability/index.md b/public/content/translations/cs/developers/docs/smart-contracts/composability/index.md index 2a2b37a5fa3..c0bff0d53bb 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/composability/index.md @@ -1,13 +1,13 @@ --- -title: Složitelnost chytrých kontraktů -description: +title: "Složitelnost chytrých kontraktů" +description: "Zjistěte, jak lze chytré kontrakty kombinovat jako kostky Lega a vytvářet tak komplexní dapps s využitím existujících komponent." lang: cs incomplete: true --- -## Stručné představení {#a-brief-introduction} +## Stručný úvod {#a-brief-introduction} -Chytré kontrakty na Ethereu jsou veřejné a lze je považovat za otevřená API. Nemusíte napsat vlastní chytrý kontrakt, abyste se stali vývojářem dapp, stačí vědět, jak s nimi pracovat. Například můžete použít existující chytré kontrakty [Uniswapu](https://uniswap.exchange/swap), decentralizované burzy, k obsluze veškeré logiky pro směnu tokenů ve vaší aplikaci – nemusíte začínat od nuly. Podívejte se na některé z jejich kontraktů [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) a [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts). +Chytré kontrakty na Ethereu jsou veřejné a lze je považovat za otevřená API. Nemusíte napsat vlastní chytrý kontrakt, abyste se stali vývojářem dapp, stačí vědět, jak s nimi pracovat. Můžete například použít stávající chytré kontrakty [Uniswapu](https://uniswap.exchange/swap), decentralizované burzy, k obsluze veškeré logiky pro směnu tokenů ve vaší aplikaci – nemusíte začínat od nuly. Podívejte se na některé z jejich kontraktů [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) a [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts). ## Co je to složitelnost? {#what-is-composability} @@ -19,17 +19,17 @@ Na Ethereu je každý chytrý kontrakt jakousi kostkou Lego – můžete použí Chytré kontrakty na Ethereu jsou jako veřejná API, takže s nimi může kdokoli pracovat nebo je integrovat do své dappky za účelem přidání funkcionality. Složitelnost chytrých kontraktů obecně funguje na třech principech: modularita, autonomie a objevitelnost: -**1. Modularita**: Schopnost jednotlivých komponent vykonávat specifickou úlohu. Na Ethereu má každý chytrý kontrakt specifické použití (jak je ukázáno v příkladu Uniswapu). +**1.** Modularita\*\*: Schopnost jednotlivých komponent vykonávat specifickou úlohu. Na Ethereu má každý chytrý kontrakt specifické použití (jak je ukázáno v příkladu Uniswapu). -**2. Autonomie**: Složitelné komponenty musí být schopny fungovat nezávisle. Každý chytrý kontrakt na Ethereu je samostatně vykonávaný a může fungovat bez závislosti na jiných částech systému. +**2.** Autonomie\*\*: Složitelné komponenty musí být schopny fungovat nezávisle. Každý chytrý kontrakt na Ethereu je samostatně vykonávaný a může fungovat bez závislosti na jiných částech systému. -**3. Objevitelnost**: Vývojáři nemohou volat externí kontrakty nebo integrovat softwarové knihovny do aplikací, pokud nejsou veřejně dostupné. Chytré kontrakty jsou z podstaty open-source; kdokoli je může volat nebo může kódovou základnu větvit. +**3.** Objevitelnost\*\*: Vývojáři nemohou volat externí kontrakty nebo integrovat softwarové knihovny do aplikací, pokud nejsou veřejně dostupné. Chytré kontrakty jsou z podstaty open-source; kdokoli je může volat nebo může kódovou základnu větvit. ## Výhody složitelnosti {#benefits-of-composability} ### Kratší vývojový cyklus {#shorter-development-cycle} -Složitelnost zmenšuje množství práce, kterou musí vývojáři při vytváření [dappek](/apps/#what-are-dapps) udělat. [Jak říká Naval Ravikant](https://twitter.com/naval/status/1444366754650656770): „Open source znamená, že každý problém musí být vyřešen pouze jednou.“ +Složitelnost snižuje množství práce, kterou musí vývojáři odvést při vytváření [dapps](/apps/#what-are-dapps). [Jak říká Naval Ravikant:](https://twitter.com/naval/status/1444366754650656770) „Open source znamená, že každý problém stačí vyřešit pouze jednou.“ Pokud existuje chytrý kontrakt, který řeší jeden problém, mohou ho ostatní vývojáři znovu použít, takže nemusí řešit stejný problém znovu. Tímto způsobem mohou vzít existující softwarové knihovny a přidat k nim další funkce, když vyvíjejí novou dappku. @@ -43,34 +43,34 @@ Interoperabilita mezi komponentami ekosystému Ethereum zlepšuje uživatelskou K ilustraci výhod interoperability použijeme příklad z arbitrážního obchodování: -Pokud se token obchoduje na `burze A` za vyšší cenu než na `burze B`, můžete využít cenový rozdíl k dosažení zisku. To však můžete udělat, pouze pokud máte dostatek prostředků k financování transakce (tj. nákup tokenu na `burze B` a prodej na `burze A`). +Pokud se token obchoduje na `exchange A` za vyšší cenu než na `exchange B`, můžete využít cenový rozdíl k dosažení zisku. To však můžete udělat, pouze pokud máte dostatek prostředků k financování transakce (tj. nákup tokenu na `exchange B` a prodej na `exchange A`). -V situaci, kdy nemáte dostatek prostředků na pokrytí takové směny, může být řešením blesková půjčka. [Bleskové půjčky](/defi/#flash-loans) jsou vysoce technické, ale základní myšlenkou je, že si můžete půjčit aktiva (bez zástavy) a ještě je stihnout v rámci _jedné_ transakce vrátit. +V situaci, kdy nemáte dostatek prostředků na pokrytí takové směny, může být řešením blesková půjčka. [Bleskové půjčky](/defi/#flash-loans) jsou vysoce technické, ale základní myšlenkou je, že si můžete půjčit aktiva (bez zástavy) a vrátit je v rámci _jedné_ transakce. -Vrátíme-li se k našemu původnímu příkladu, arbitrážní obchodník si může vzít velkou bleskovou půjčku, nakoupit tokeny na `burze B`, prodat je na `burze A`, splatit půjčený kapitál i s úroky a vydělat na tom, to vše v rámci jedné transakce. Tato složitá logika vyžaduje kombinování volání více kontraktů, což by nebylo možné, kdyby chytré kontrakty neměly interoperabilitu. +Když se vrátíme k našemu úvodnímu příkladu, arbitrážní obchodník si může vzít velkou bleskovou půjčku, nakoupit tokeny na `exchange B`, prodat je na `exchange A`, splatit kapitál + úrok a ponechat si zisk, a to vše v rámci jedné transakce. Tato složitá logika vyžaduje kombinování volání více kontraktů, což by nebylo možné, kdyby chytré kontrakty neměly interoperabilitu. -## Příklady složitelnosti na Ethereu {#composability-in-ethereum} +## Příklady složitelnosti v Ethereu {#composability-in-ethereum} ### Směny tokenů {#token-swaps} Pokud vytvoříte dappku, která vyžaduje platbu za transakce v ETH, můžete uživatelům umožnit platit v jiných ERC-20 tokenech a to pomocí zavedení logiky pro směnu tokenů. Kód automaticky převede token uživatele na ETH, než kontrakt vykoná volanou funkci. -### Řízení {#governance} +### Správa {#governance} -Tvorba na míru šitých řídicích systémů pro [DAO](/dao/) může být drahá a časově náročná. Místo toho můžete k rychlému vytvoření řídicího frameworku pro vaše DAO použít open-source toolkit řízení, jako je [Aragon Client](https://client.aragon.org/). +Vytváření systémů správy na míru pro [DAO](/dao/) může být nákladné a časově náročné. Místo toho můžete použít open-source sadu nástrojů pro správu, jako je [Aragon Client](https://client.aragon.org/), k nastartování svého DAO a rychlému vytvoření rámce pro správu. ### Správa identity {#identity-management} -Místo vytváření vlastního autentizačního systému nebo nutnosti spoléhat se na centralizované poskytovatele, můžete ke správě autentizace uživatelů integrovat nástroje pro decentralizovanou identitu (DID). Příkladem je [SpruceID](https://www.spruceid.com/), open-source toolkit, který nabízí funkci „Přihlásit se pomocí Etherea“, která uživatelům umožňuje autentizovat identitu pomocí ethereovské peněženky. +Místo vytváření vlastního autentizačního systému nebo nutnosti spoléhat se na centralizované poskytovatele, můžete ke správě autentizace uživatelů integrovat nástroje pro decentralizovanou identitu (DID). Příkladem je [SpruceID](https://www.spruceid.com/), open-source sada nástrojů, která nabízí funkci „Přihlásit se pomocí Etherea“, která uživatelům umožňuje ověřovat identitu pomocí ethereovské peněženky. ## Související návody {#related-tutorials} -- [Nastartujte vývoj frontendového rozhraní pro dappky pomocí create-eth-app](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Přehled o tom, jak používat create-eth-app k vytváření aplikací s populárními chytrými kontrakty._ +- [Nastartujte vývoj frontendu pro dapps s create-eth-app](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Přehled, jak použít create-eth-app k vytváření aplikací s populárními chytrými kontrakty, které jsou okamžitě k dispozici._ -## Další informace {#further-reading} +## Další čtení {#further-reading} _Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ -- [Složitelnost je inovace](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/) +- [Složitelnost je inovace](https://a16zcrypto.com/posts/article/how-composability-unlocks-crypto-and-everything-else/) - [Proč je složitelnost důležitá pro Web3](https://hackernoon.com/why-composability-matters-for-web3) -- [Co je to složitelnost?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) +- [Co je složitelnost?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/deploying/index.md b/public/content/translations/cs/developers/docs/smart-contracts/deploying/index.md index 7170664377f..3ff55c93682 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/deploying/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/deploying/index.md @@ -1,6 +1,6 @@ --- -title: Nasazování chytrých smluv -description: +title: "Nasazování chytrých kontraktů" +description: "Naučte se, jak nasazovat chytré kontrakty do sítí Etherea, včetně předpokladů, nástrojů a kroků nasazení." lang: cs --- @@ -10,50 +10,50 @@ Abyste nasadili chytrý kontrakt, stačí odeslat Ethereum transakci obsahujíc ## Předpoklady {#prerequisites} -Než nasadíte chytrý kontrakt, měli byste vědět o [Ethereum sítích](/developers/docs/networks/), [transakcích](/developers/docs/transactions/) a [anatomii chytrých kontraktů](/developers/docs/smart-contracts/anatomy/). +Před nasazením chytrých kontraktů byste měli rozumět [sítím Etherea](/developers/docs/networks/), [transakcím](/developers/docs/transactions/) a [anatomii chytrých kontraktů](/developers/docs/smart-contracts/anatomy/). -Nasazení smlouvy také stojí ethery (ETH), protože jsou uloženy na blockchainu, takže byste měli vědět o [palivech a poplatcích](/developers/docs/gas/) na Ethereu. +Nasazení kontraktu také stojí ethery (ETH), protože jsou uloženy na blockchainu, takže byste měli být obeznámeni s [plynem a poplatky](/developers/docs/gas/) na Ethereu. -Nakonec budete muset kontrakt před nasazením zkompilovat, takže se ujistěte, že jste si přečetli o [kompilování chytrých kontraktů](/developers/docs/smart-contracts/compiling/). +Nakonec budete muset svůj kontrakt před nasazením zkompilovat, takže se ujistěte, že jste si přečetli o [kompilaci chytrých kontraktů](/developers/docs/smart-contracts/compiling/). ## Jak nasadit chytrý kontrakt {#how-to-deploy-a-smart-contract} ### Co budete potřebovat {#what-youll-need} -- Bytecode vašeho kontraktu – generuje se při [kompilování](/developers/docs/smart-contracts/compiling/) +- Bajtkód vašeho kontraktu – ten je generován [kompilací](/developers/docs/smart-contracts/compiling/) - ETH na palivo – nastavíte si svůj palivový limit jako další transakce, takže počítejte s tím, že nasazení kontraktu potřebuje mnohem více paliva než prostý převod ETH - Script nasazení nebo plugin -- Přístup k [uzlu Etherea](/developers/docs/nodes-and-clients/), a to buď provozováním vlastního, připojením k veřejnému uzlu, nebo prostřednictvím API klíče pomocí [služby uzlů](/developers/docs/nodes-and-clients/nodes-as-a-service/) +- Přístup k [uzlu Ethereum](/developers/docs/nodes-and-clients/), buď spuštěním vlastního uzlu, připojením k veřejnému uzlu, nebo pomocí klíče API s využitím [služby poskytující uzly](/developers/docs/nodes-and-clients/nodes-as-a-service/) ### Kroky k nasazení chytrého kontraktu {#steps-to-deploy} -Konkrétní kroky závisí na daném vývojovém frameworku. Můžete se například podívat do [Hardhat dokumentace o nasazování kontraktů](https://hardhat.org/docs/tutorial/deploying) nebo do [Foundry dokumentace o nasazování a ověřování chytrého kontraktu](https://book.getfoundry.sh/forge/deploying). Po nasazení bude mít váš kontrakt adresu Etherea jako ostatní [účty](/developers/docs/accounts/) a lze jej ověřit pomocí [nástrojů pro ověření zdrojového kódu](/developers/docs/smart-contracts/verifying/#source-code-verification-tools). +Konkrétní kroky závisí na daném vývojovém frameworku. Můžete se například podívat do [dokumentace Hardhat o nasazování kontraktů](https://hardhat.org/docs/tutorial/deploying) nebo do [dokumentace Foundry o nasazování a ověřování chytrého kontraktu](https://book.getfoundry.sh/forge/deploying). Po nasazení bude mít váš kontrakt ethereovou adresu jako jiné [účty](/developers/docs/accounts/) a lze jej ověřit pomocí [nástrojů pro ověření zdrojového kódu](/developers/docs/smart-contracts/verifying/#source-code-verification-tools). ## Související nástroje {#related-tools} -**Remix – _remix IDE umožňuje vyvíjet, nasazovat a spravovat chytré kontrakty pro blockchainy typu Etherea_** +**Remix – _Remix IDE umožňuje vyvíjet, nasazovat a spravovat chytré kontrakty pro blockchainy typu Etherea_** - [Remix](https://remix.ethereum.org) -**Tenderly – _platforma na vývoj Web3, která poskytuje ladění, pozorovatelnost a infrastrukturní stavební bloky pro vývoj, testování, monitorování a provozování chytrých kontraktů_** +**Tenderly – _Web3 vývojová platforma, která poskytuje ladění, pozorovatelnost a infrastrukturní stavební bloky pro vývoj, testování, monitorování a provozování chytrých kontraktů_** - [tenderly.co](https://tenderly.co/) -- [Dokumentace](https://docs.tenderly.co/) +- [Docs](https://docs.tenderly.co/) - [GitHub](https://github.com/Tenderly) - [Discord](https://discord.gg/eCWjuvt) -**Hardhat – _vývojové prostředí pro kompilaci, nasazení, testování a ladění Ethereum softwaru_** +**Hardhat – _Vývojové prostředí pro kompilaci, nasazení, testování a ladění vašeho softwaru pro Ethereum_** - [hardhat.org](https://hardhat.org/getting-started/) -- [Dokumentace na nasazování vašich kontraktů](https://hardhat.org/docs/tutorial/deploying) +- [Dokumentace o nasazování vašich kontraktů](https://hardhat.org/docs/tutorial/deploying) - [GitHub](https://github.com/nomiclabs/hardhat) - [Discord](https://discord.com/invite/TETZs2KK4k) -**thirdweb – _lehce nasaďte libovolný kontrakt do libovolného blockchainu kompatibilního s EVM pomocí jediného příkazu_** +**thirdweb – _Snadné nasazení jakéhokoli kontraktu na jakýkoli řetězec kompatibilní s EVM pomocí jediného příkazu_** - [Dokumentace](https://portal.thirdweb.com/deploy/) -**Crossmint – _vývojová platforma na úrovni webu3 pro nasazení chytrých kontraktů, umožnění plateb kreditními kartami a plateb napříč blockchainy a používání API k vytváření, distribuci, prodeji, ukládání a úpravám NFT_** +**Crossmint – _Web3 vývojová platforma podnikové úrovně pro nasazování chytrých kontraktů, umožnění plateb kreditní kartou a plateb mezi řetězci a používání API k vytváření, distribuci, prodeji, ukládání a úpravě NFT._** - [crossmint.com](https://www.crossmint.com) - [Dokumentace](https://docs.crossmint.com) @@ -62,20 +62,20 @@ Konkrétní kroky závisí na daném vývojovém frameworku. Můžete se napří ## Související návody {#related-tutorials} -- [Nasazení vašeho prvního chytrého kontraktu](/developers/tutorials/deploying-your-first-smart-contract/) _– úvod do nasazení prvního chytrého kontraktu v testovací síti Etherea._ -- [Ahoj Světe | tutoriál na chytrý kontrakt](/developers/tutorials/hello-world-smart-contract/) _– jednoduchý návod na vytvoření a nasazení základního chytrého kontraktu na Ethereu._ -- [Interagujte s dalšími kontrakty ze Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– jak nasadit chytrý kontrakt z existujícího kontraktu a interagovat s ním._ -- [Jak snížit velikost kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– jak snížit velikost kontraktu, abyste nepřekročili limit a ušetřili za palivo_ +- [Nasazení vašeho prvního chytrého kontraktu](/developers/tutorials/deploying-your-first-smart-contract/) _– Úvod do nasazení vašeho prvního chytrého kontraktu v testovací síti Etherea._ +- [Ahoj světe | tutoriál na chytrý kontrakt](/developers/tutorials/hello-world-smart-contract/) _– Jednoduchý návod na vytvoření a nasazení základního chytrého kontraktu na Ethereu._ +- [Interakce s dalšími kontrakty ze Solidity](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Jak nasadit chytrý kontrakt z existujícího kontraktu a interagovat s ním._ +- [Jak zmenšit velikost vašeho kontraktu](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Jak zmenšit velikost vašeho kontraktu, abyste se vešli do limitu a ušetřili za plyn_ -## Další informace {#further-reading} +## Další čtení {#further-reading} - [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) – _OpenZeppelin_ -- [Nasazení vašich kontraktů pomocí Hardhat](https://hardhat.org/docs/tutorial/deploying) – _Nomic Labs_ +- [Nasazování vašich kontraktů s Hardhat](https://hardhat.org/docs/tutorial/deploying) – _Nomic Labs_ -_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!_ ## Související témata {#related-topics} -- [Vývojářské rámce](/developers/docs/frameworks/) -- [Run an Ethereum node](/developers/docs/nodes-and-clients/run-a-node/) -- [Uzly jako služba](/developers/docs/nodes-and-clients/nodes-as-a-service) +- [Vývojářské frameworky](/developers/docs/frameworks/) +- [Spuštění uzlu Ethereum](/developers/docs/nodes-and-clients/run-a-node/) +- [Uzel jako služba](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/cs/developers/docs/smart-contracts/formal-verification/index.md index 7004bb0202a..9f645a05e7f 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/formal-verification/index.md @@ -1,12 +1,12 @@ --- -title: Formální ověření chytrých kontraktů -description: Přehled formálního ověření pro chytré kontrakty na Ethereu +title: "Formální ověření chytrých kontraktů" +description: "Přehled formálního ověření pro chytré kontrakty na Ethereu" lang: cs --- -[Chytré kontrakty](/developers/docs/smart-contracts/) umožňují vytvářet decentralizované, důvěryhodné a robustní aplikace, které nabízejí nová využití a jsou pro uživatele přínosem. Protože chytré kontrakty spravují hodnotná aktiva, bezpečnost je pro vývojáře kritická. +[Chytré kontrakty](/developers/docs/smart-contracts/) umožňují vytvářet decentralizované a robustní aplikace nevyžadující důvěru, které představují nové případy užití a odemykají hodnotu pro uživatele. Protože chytré kontrakty spravují hodnotná aktiva, bezpečnost je pro vývojáře kritická. -Formální verifikace je jednou z doporučených technik pro zlepšení bezpečnosti [chytrých kontraktů](/developers/docs/smart-contracts/security/). Formální verifikace, která používá [formální metody](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) pro specifikaci, návrh a ověřování programů, se již léta používá k zajištění správnosti kritických hardwarových a softwarových systémů. +Formální ověření je jednou z doporučených technik pro zlepšení [bezpečnosti chytrých kontraktů](/developers/docs/smart-contracts/security/). Formální ověření, které používá [formální metody](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) pro specifikaci, návrh a ověřování programů, se již léta používá k zajištění správnosti kritických hardwarových a softwarových systémů. Když je formální verifikace implementována v chytrých kontraktech, může dokázat, že obchodní logika kontraktu splňuje předem definovanou specifikaci. Ve srovnání s jinými metodami pro hodnocení správnosti kódu kontraktu, jako je testování, poskytuje formální verifikace silnější záruky, že chytrý kontrakt je funkčně správný. @@ -18,7 +18,7 @@ Očekávané chování systému (v tomto případě chytrého kontraktu) je pops ### Co je formální model? {#what-is-a-formal-model} -Ve výpočetní technice je [formální model](https://en.wikipedia.org/wiki/Model_of_computation) matematický popis výpočetního procesu. Programy jsou abstrahovány do matematických funkcí (rovnic) a model popisuje, jak se výstupy funkcí vypočítávají na základě zadaných vstupů. +V počítačové vědě je [formální model](https://en.wikipedia.org/wiki/Model_of_computation) matematickým popisem výpočetního procesu. Programy jsou abstrahovány do matematických funkcí (rovnic) a model popisuje, jak se výstupy funkcí vypočítávají na základě zadaných vstupů. Formální modely poskytují úroveň abstrakce, nad kterou lze analyzovat chování programu. Existence formálních modelů umožňuje vytvoření _formální specifikace_, která popisuje požadované vlastnosti daného modelu. @@ -26,15 +26,15 @@ Pro modelování chytrých kontraktů za účelem formální verifikace se použ Modely na vysoké úrovni se zaměřují na vztah mezi chytrými kontrakty a externími agenty, jako jsou externě vlastněné účty (EOAs), kontraktové účty a blockchainové prostředí. Tyto modely jsou užitečné pro definování vlastností určujících, jak by se měl kontrakt chovat v reakci na předem dané interakce uživatelů. -Naopak, jiné formální modely se zaměřují na chování chytrého kontraktu na nižší úrovni. Zatímco modely zkoumající chování kontraktů na vysoké úrovni mohou pomoci při úvahách o funkčnosti kontraktu, není vyloučeno jejich selhání při zachycování detailů o interních mechanismech implementace. Modely pro nízké úrovně na analýzu programu aplikují pohled „bílé skříňky“ a spoléhají na nižší úroveň reprezentací aplikací chytrých kontraktů, jako jsou programové stopy a [grafy toku řízení](https://en.wikipedia.org/wiki/Control-flow_graph), za účelem úvah o relevantních vlastnostech pro vykonávání kontraktu. +Naopak, jiné formální modely se zaměřují na chování chytrého kontraktu na nižší úrovni. Zatímco modely zkoumající chování kontraktů na vysoké úrovni mohou pomoci při úvahách o funkčnosti kontraktu, není vyloučeno jejich selhání při zachycování detailů o interních mechanismech implementace. Nízkoúrovňové modely uplatňují při analýze programu pohled „bílé skříňky“ a spoléhají se na nízkoúrovňové reprezentace aplikací s chytrými kontrakty, jako je trasování programu a [grafy řídicího toku](https://en.wikipedia.org/wiki/Control-flow_graph), aby bylo možné usuzovat o vlastnostech relevantních pro provádění kontraktu. -Modely nízké úrovně jsou považovány za ideální, protože reprezentují skutečnou exekuci chytrého kontraktu v prostředí Etherea (tj. v [EVM](/developers/docs/evm/)). Techniky modelování na nízké úrovni jsou zvláště užitečné při stanovování kritických bezpečnostních vlastností chytrých kontraktů a detekci potenciálních zranitelností. +Nízkoúrovňové modely jsou považovány za ideální, protože představují skutečné provedení chytrého kontraktu v exekučním prostředí Etherea (tj. v [EVM](/developers/docs/evm/)). Techniky modelování na nízké úrovni jsou zvláště užitečné při stanovování kritických bezpečnostních vlastností chytrých kontraktů a detekci potenciálních zranitelností. ### Co je formální specifikace? {#what-is-a-formal-specification} Specifikace je jednoduše řečeno technický požadavek, který musí daný systém splňovat. V programování představují specifikace obecné představy o provádění programu (tj. co by měl program dělat). -V kontextu chytrých kontraktů se formální specifikace týkají _vlastností_ – formálních popisů požadavků, které musí kontrakt splňovat. Takové vlastnosti se označují jako „invarianty“ a představují logická tvrzení o provádění kontraktu, která musí zůstat pravdivá za všech okolností, bez jakýchkoliv výjimek. +V kontextu chytrých kontraktů se formální specifikace vztahují na _vlastnosti_ – formální popisy požadavků, které musí kontrakt splňovat. Takové vlastnosti se označují jako „invarianty“ a představují logická tvrzení o provádění kontraktu, která musí zůstat pravdivá za všech okolností, bez jakýchkoliv výjimek. Formální verifikaci tedy můžeme považovat za sbírku tvrzení napsaných ve formálním jazyce, která popisují zamýšlený výkon chytrého kontraktu. Specifikace pokrývají vlastnosti kontraktu a definují, jak by se měl chovat v různých situacích. Účelem formální verifikace je zjistit, zda chytrý kontrakt tyto vlastnosti (invarianty) má a zda nejsou tyto vlastnosti během provádění porušeny. @@ -44,55 +44,55 @@ Formální specifikace jsou klíčové při vývoji bezpečných implementací c Formální specifikace umožňují matematické uvažování o správnosti provádění programu. Stejně jako formální modely mohou formální specifikace zachytit buď vlastnosti na vysoké úrovni, nebo chování implementace kontraktu na nízké úrovni. -Formální specifikace jsou odvozeny pomocí prvků [programové logiky](https://en.wikipedia.org/wiki/Logic_programming), která umožňuje formální uvažování o vlastnostech programu. Programová logika má formální pravidla, která vyjadřují (v matematickém jazyce) očekávané chování programu. Pro vytváření formálních specifikací se používají různé programové logiky, včetně [logiky dosažitelnosti](https://en.wikipedia.org/wiki/Reachability_problem), [temporální logiky](https://en.wikipedia.org/wiki/Temporal_logic) a [Hoareovy logiky](https://en.wikipedia.org/wiki/Hoare_logic). +Formální specifikace jsou odvozeny pomocí prvků [programovací logiky](https://en.wikipedia.org/wiki/Logic_programming), která umožňuje formální uvažování o vlastnostech programu. Programová logika má formální pravidla, která vyjadřují (v matematickém jazyce) očekávané chování programu. Při vytváření formálních specifikací se používají různé programovací logiky, včetně [logiky dosažitelnosti](https://en.wikipedia.org/wiki/Reachability_problem), [temporální logiky](https://en.wikipedia.org/wiki/Temporal_logic) a [Hoareovy logiky](https://en.wikipedia.org/wiki/Hoare_logic). -Formální specifikace pro chytré kontrakty lze obecně rozdělit na specifikace na **vysoké úrovni** a specifikace na **nízké úrovni**. Bez ohledu na to, do které kategorie specifikace patří, musí adekvátně a jednoznačně popisovat vlastnost systému, který je podroben analýze. +Formální specifikace pro chytré kontrakty lze obecně rozdělit na **vysokoúrovňové** a **nízkoúrovňové** specifikace. Bez ohledu na to, do které kategorie specifikace patří, musí adekvátně a jednoznačně popisovat vlastnost systému, který je podroben analýze. -### Specifikace na vysoké úrovni {#high-level-specifications} +### Vysokoúrovňové specifikace {#high-level-specifications} -Jak název napovídá, specifikace na vysoké úrovni (také nazývané „modelově orientované specifikace“) popisují chování programu na vysoké úrovni. Specifikace na vysoké úrovni modelují chytrý kontrakt jako [konečný automat](https://en.wikipedia.org/wiki/Finite-state_machine) (final state machine, FSM), který může prováděním operací přecházet mezi stavy, přičemž pro definování formálních vlastností modelu FSM se používá temporální logika. +Jak název napovídá, specifikace na vysoké úrovni (také nazývané „modelově orientované specifikace“) popisují chování programu na vysoké úrovni. Vysokoúrovňové specifikace modelují chytrý kontrakt jako [konečný stavový automat](https://en.wikipedia.org/wiki/Finite-state_machine) (FSM), který může přecházet mezi stavy prováděním operací, přičemž k definování formálních vlastností modelu FSM se používá temporální logika. -[Temporální logiky](https://en.wikipedia.org/wiki/Temporal_logic) jsou „pravidla pro uvažování o tvrzeních kvalifikovaných z hlediska času (např. „_vždy_ mám hlad“ nebo „_nakonec_ budu mít hlad“)“. Když se aplikují na formální verifikaci, temporální logiky se používají k vyjádření tvrzení o správném chování systémů modelovaných jako automaty. Konkrétně popisuje temporální logika budoucí stavy, ve kterých se chytrý kontrakt může nacházet, a jak mezi těmito stavy přechází. +[Temporální logiky](https://en.wikipedia.org/wiki/Temporal_logic) jsou „pravidla pro uvažování o tvrzeních kvalifikovaných z hlediska času (např. „_vždycky_ mám hlad“ nebo „_nakonec_ budu mít hlad“).“ Když se aplikují na formální verifikaci, temporální logiky se používají k vyjádření tvrzení o správném chování systémů modelovaných jako automaty. Konkrétně popisuje temporální logika budoucí stavy, ve kterých se chytrý kontrakt může nacházet, a jak mezi těmito stavy přechází. -Specifikace na vysoké úrovni obecně zachycují dvě klíčové temporální vlastnosti chytrých kontraktů: **bezpečnost** a **živost**. Bezpečnostní vlastnosti představují myšlenku, že „nic špatného se nikdy nestane“ a obvykle vyjadřují invarianty. Bezpečnostní vlastnost může definovat obecné softwarové požadavky, jako je ochrana před [zablokováním](https://www.techtarget.com/whatis/definition/deadlock), nebo vyjadřovat specifické vlastnosti pro chytré kontrakty (např. invarianty týkající se přístupu k funkcím, přípustné hodnoty stavových proměnných nebo podmínky pro převod tokenů). +Vysokoúrovňové specifikace obecně zachycují dvě kritické časové vlastnosti chytrých kontraktů: **bezpečnost** a **živost**. Bezpečnostní vlastnosti představují myšlenku, že „nic špatného se nikdy nestane“ a obvykle vyjadřují invarianty. Bezpečnostní vlastnost může definovat obecné softwarové požadavky, jako je ochrana před [zablokováním](https://www.techtarget.com/whatis/definition/deadlock), nebo vyjadřovat vlastnosti specifické pro doménu kontraktů (např. invarianty řízení přístupu k funkcím, přípustné hodnoty stavových proměnných nebo podmínky pro převody tokenů). -Vezměme si pro příklad tento bezpečnostní požadavek, který pokrývá podmínky pro použití funkcí `transfer()` nebo `transferFrom()` v ERC-20 tokenových kontraktech: _„Zůstatek odesílatele nikdy nesmí být nižší než požadované množství tokenů, které mají být odeslány.“_ Tento popis invariantu kontraktu v přirozeném jazyce lze převést do formální (matematické) specifikace, která pak může být rigorózně ověřena z hlediska platnosti. +Jako příklad si vezměme tento bezpečnostní požadavek, který se vztahuje na podmínky pro použití funkcí `transfer()` nebo `transferFrom()` v kontraktech s tokeny ERC-20: _„Zůstatek odesílatele není nikdy nižší než požadované množství tokenů k odeslání.“_. Tento popis invariantu kontraktu v přirozeném jazyce lze převést do formální (matematické) specifikace, která pak může být rigorózně ověřena z hlediska platnosti. -Živostní vlastnosti zajišťují, že „se ve výsledku stane něco dobrého“, a týkají se schopnosti kontraktu přepínat mezi různými stavy. Příkladem živostní vlastnosti je „likvidita“, která odkazuje na schopnost kontraktu převádět své zůstatky uživatelům na základě žádosti. Pokud je tato vlastnost porušena, uživatelé nejsou schopni vybrat aktiva uložená v kontraktu, jako se to stalo při incidentu s [Parity peněženkou](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html). +Živostní vlastnosti zajišťují, že „se ve výsledku stane něco dobrého“, a týkají se schopnosti kontraktu přepínat mezi různými stavy. Příkladem živostní vlastnosti je „likvidita“, která odkazuje na schopnost kontraktu převádět své zůstatky uživatelům na základě žádosti. Pokud je tato vlastnost porušena, uživatelé nebudou moci vybrat prostředky uložené v kontraktu, jako se to stalo při [incidentu s peněženkou Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html). -### Specifikace na nízké úrovni {#low-level-specifications} +### Nízkoúrovňové specifikace {#low-level-specifications} Specifikace na vysoké úrovni berou jako výchozí bod model konečného automatu kontraktu a definují požadované vlastnosti tohoto modelu. Naopak specifikace na nízké úrovni (také nazývané „specifikace orientované na vlastnosti“) často modelují programy (chytré kontrakty) jako systémy skládající se ze sbírky matematických funkcí a popisují správné chování těchto systémů. -Jednoduše řečeno, specifikace na nízké úrovni analyzují _sledy funkcí programu_ a snaží se definovat vlastnosti chytrého kontraktu na základě těchto sledů. Sledy odkazují na sekvence provádění funkcí, které mění stav chytrého kontraktu; proto specifikace na nízké úrovni pomáhají specifikovat požadavky na interní exekuci kontraktu. +Jednoduše řečeno, nízkoúrovňové specifikace analyzují _trasování programu_ a pokoušejí se definovat vlastnosti chytrého kontraktu na základě tohoto trasování. Sledy odkazují na sekvence provádění funkcí, které mění stav chytrého kontraktu; proto specifikace na nízké úrovni pomáhají specifikovat požadavky na interní exekuci kontraktu. Formální specifikace na nízké úrovni mohou být uvedeny buď jako vlastnosti ve stylu Hoareovy logiky, nebo jako invarianty na exekučních cestách. ### Vlastnosti ve stylu Hoareovy logiky {#hoare-style-properties} -[Hoareova logika](https://en.wikipedia.org/wiki/Hoare_logic) poskytuje sadu formálních pravidel pro uvažování o správnosti programů, včetně chytrých kontraktů. Vlastnost ve stylu Hoareovy logiky je reprezentována jako Hoareova trojice \{_P_}_c_\{_Q_}, kde _c_ je program a _P_ a _Q_ jsou predikáty na stavu _c_ (tj. programu), formálně popsané jako _předpoklady_ a _podmínky následku_. +[Hoareova logika](https://en.wikipedia.org/wiki/Hoare_logic) poskytuje sadu formálních pravidel pro uvažování o správnosti programů, včetně chytrých kontraktů. Vlastnost ve stylu Hoareovy logiky je reprezentována Hoareovou trojicí `{P}c{Q}`, kde `c` je program a `P` a `Q` jsou predikáty stavu `c` (tj. programu), formálně popsané jako _vstupní podmínky_ a _výstupní podmínky_. Předpoklad je predikát popisující podmínky potřebné pro správné provedení funkce; uživatelé volající kontrakt musí tuto podmínku splnit. Podmínka následku je predikát popisující podmínku, kterou funkce stanoví, pokud je správně provedena; uživatelé mohou očekávat, že tato podmínka bude po volání funkce pravdivá. _Invariant_ v Hoareově logice je predikát, který je zachován při provádění funkce (tj. nemění se). -Specifikace ve stylu Hoareovy logiky mohou zaručit buď _částečnou správnost_, _nebo úplnou správnost_. Implementace funkce kontraktu je „částečně správná“, pokud předpoklad platí před provedením funkce a když provedení končí, podmínka následku je také pravdivá. Důkaz úplné správnosti je obdržen, pokud je předpoklad pravdivý před provedením funkce, dále je zaručeno, že provádění funkce bude ukončeno, a když k tomu dojde, následek bude pravdivý. +Specifikace ve stylu Hoareovy logiky mohou zaručit buď _částečnou správnost_, nebo _úplnou správnost_. Implementace funkce kontraktu je „částečně správná“, pokud předpoklad platí před provedením funkce a když provedení končí, podmínka následku je také pravdivá. Důkaz úplné správnosti je obdržen, pokud je předpoklad pravdivý před provedením funkce, dále je zaručeno, že provádění funkce bude ukončeno, a když k tomu dojde, následek bude pravdivý. Získání důkazu o úplné správnosti je obtížné, protože některá provedení se mohou před ukončením opozdit, nebo nemusí být dokončena vůbec. To znamená, že otázka, zda provedení skončí, je pravděpodobně diskutabilní, protože mechanismus paliva na Ethereu zabraňuje nekonečným smyčkám programu (provádění buď úspěšně skončí, nebo skončí kvůli chybě „došlo palivo“). Specifikace chytrých kontraktů vytvořené pomocí Hoareovy logiky budou mít definovány předpoklady, podmínky následku a invarianty pro provedení funkcí a smyček kontraktu. Předpoklady často zahrnují možnost chybných vstupů funkce, přičemž následky popisují očekávanou reakci na takové vstupy (např. vyvolání specifické výjimky). Tímto způsobem jsou vlastnosti ve stylu Hoareovy logiky účinné při zajišťování správnosti implementací kontraktů. -Mnoho rámců pro formální verifikaci používá specifikace ve stylu Hoareovy logiky k prokázání sémantické správnosti funkcí. Je také možné přidat vlastnosti ve stylu Hoareovy logiky (jako tvrzení) přímo do kódu kontraktu pomocí příkazů `require` a `assert` v jazyce Solidity. +Mnoho rámců pro formální verifikaci používá specifikace ve stylu Hoareovy logiky k prokázání sémantické správnosti funkcí. Vlastnosti ve stylu Hoareovy logiky je také možné přidávat (jako tvrzení) přímo do kódu kontraktu pomocí příkazů `require` a `assert` v Solidity. -Příkazy `require` vyjadřují předpoklad nebo invariant a často se používají k ověření vstupů uživatelů, zatímco `assert` zachycuje podmínku následku nezbytnou pro bezpečnost. Například správná kontrola přístupu k funkcím (příklad bezpečnostní vlastnosti) může být zajištěna pomocí `require` jako předpokladu ověřujícího identitu volajícího účtu. Podobně lze invariant na přípustné hodnoty stavových proměnných v kontraktu (např. celkový počet tokenů v oběhu) chránit před porušením pomocí `assert`, aby se potvrdil stav kontraktu po provedení funkce. +Příkazy `require` vyjadřují vstupní podmínku nebo invariant a často se používají k ověření uživatelských vstupů, zatímco `assert` zachycuje výstupní podmínku nezbytnou pro bezpečnost. Například řádné řízení přístupu k funkcím (příklad bezpečnostní vlastnosti) lze dosáhnout pomocí příkazu `require` jako kontroly vstupní podmínky identity volajícího účtu. Podobně lze invariant přípustných hodnot stavových proměnných v kontraktu (např. celkový počet tokenů v oběhu) ochránit před porušením pomocí `assert`, který potvrdí stav kontraktu po provedení funkce. ### Vlastnosti na úrovni trasování {#trace-level-properties} Specifikace založené na trasování popisují operace, které mění různé stavy kontraktu, a vztahy mezi těmito operacemi. Jak jsme vysvětlili výše, trasy jsou sekvence operací, které mění stav kontraktu určitým způsobem. -Tento přístup se spoléhá na modelování chytrých kontraktů jako systémů změny stavů s předdefinovanými stavy (popisovanými stavovými proměnnými) spolu se souborem předdefinovaných přechodů (popisovaných funkcemi kontraktu). Dále se často používá [graf toků řízení](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), což je grafické znázornění toku provádění programu, pro popis operační sémantiky kontraktu. V něm je každá trasa reprezentována jako cesta na tomto grafu toků řízení. +Tento přístup se spoléhá na modelování chytrých kontraktů jako systémů změny stavů s předdefinovanými stavy (popisovanými stavovými proměnnými) spolu se souborem předdefinovaných přechodů (popisovaných funkcemi kontraktu). Dále se pro popis operační sémantiky kontraktu často používá [graf řídicího toku](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), což je grafické znázornění toku provádění programu. V něm je každá trasa reprezentována jako cesta na tomto grafu toků řízení. Primárně se specifikace na úrovni tras používají k úvahám o vzorcích interního provádění v chytrých kontraktech. Vytvořením specifikací na úrovni tras se ujišťujeme o přípustných cestách provedení (tj. přechodech stavů) pro daný chytrý kontrakt. Pomocí technik, jako je symbolické provádění, můžeme formálně ověřit, že provedení nikdy nenásleduje cestu, která není definována ve formálním modelu. -Použijme příklad [DAO](/dao/) kontraktu, který má několik veřejně přístupných funkcí, abychom popsali vlastnosti na úrovni tras. Pro tento příklad předpokládáme, že DAO kontrakt umožňuje uživatelům provádět následující operace: +Pro popis vlastností na úrovni trasování použijme příklad kontraktu [DAO](/dao/), který má několik veřejně přístupných funkcí. Pro tento příklad předpokládáme, že DAO kontrakt umožňuje uživatelům provádět následující operace: - Vklad prostředků @@ -100,27 +100,27 @@ Použijme příklad [DAO](/dao/) kontraktu, který má několik veřejně přís - Požadování vrácení peněz, pokud uživatelé o návrhu nehlasovali -Příklady vlastností na úrovni tras by mohly být _„uživatelé, kteří nevložili prostředky, nemohou hlasovat o návrhu“_ nebo _„uživatelé, kteří nehlasovali o návrhu, by měli mít vždy možnost požádat o vrácení peněz“_. Obě vlastnosti zajišťují preferované sekvence provádění (hlasování nemůže probíhat _před_ vložením prostředků a požadování vrácení peněz nemůže probíhat _po_ hlasování o návrhu). +Příkladem vlastností na úrovni trasování může být _„uživatelé, kteří nevloží prostředky, nemohou hlasovat o návrhu“_ nebo _„uživatelé, kteří nehlasují o návrhu, by měli mít vždy možnost požádat o vrácení peněz“_. Obě vlastnosti zajišťují upřednostňované posloupnosti provádění (hlasování nemůže proběhnout _před_ vložením prostředků a žádost o vrácení peněz nemůže proběhnout _po_ hlasování o návrhu). -## Techniky formální verifikace pro chytré kontrakty {#formal-verification-techniques} +## Techniky formálního ověření chytrých kontraktů {#formal-verification-techniques} -### Kontrola modelu {#model-checking} +### Kontrola modelů {#model-checking} Kontrola modelu je technika formální verifikace, při které algoritmus kontroluje formální model chytrého kontraktu vůči jeho specifikaci. Při kontrole modelu jsou chytré kontrakty často reprezentovány jako systémy přechodu stavů, zatímco vlastnosti přípustných stavů kontraktu jsou definovány pomocí dočasné logiky. -Kontrola modelu vyžaduje vytvoření abstraktní matematické reprezentace systému (tj. kontraktu) a vyjádření vlastností tohoto systému pomocí vzorců založených na [výrokové logice](https://www.baeldung.com/cs/propositional-logic). To zjednodušuje úkol algoritmu kontroly modelu, kterým je možné prokázat, že matematický model splňuje daný logický vzorec. +Kontrola modelů vyžaduje vytvoření abstraktní matematické reprezentace systému (tj. kontraktu) a vyjádření vlastností tohoto systému pomocí vzorců založených na [výrokové logice](https://www.baeldung.com/cs/propositional-logic). To zjednodušuje úkol algoritmu kontroly modelu, kterým je možné prokázat, že matematický model splňuje daný logický vzorec. -Kontrola modelu se ve formální verifikaci primárně používá k vyhodnocení dočasných vlastností, které popisují chování kontraktu v průběhu času. Dočasné vlastnosti pro chytré kontrakty zahrnují _bezpečnost_ a _živost_, které jsme vysvětlili dříve. +Kontrola modelu se ve formální verifikaci primárně používá k vyhodnocení dočasných vlastností, které popisují chování kontraktu v průběhu času. Časové vlastnosti chytrých kontraktů zahrnují _bezpečnost_ a _živost_, které jsme vysvětlili dříve. -Například bezpečnostní vlastnost týkající se kontroly přístupu (např. _Pouze vlastník kontraktu může volat `selfdestruct`_) může být napsána ve formální logice. Poté může algoritmus kontroly modelu ověřit, zda kontrakt splňuje tuto formální specifikaci. +Například bezpečnostní vlastnost související s řízením přístupu (např. _pouze vlastník kontraktu může volat `selfdestruct`_) může být zapsána ve formální logice. Poté může algoritmus kontroly modelu ověřit, zda kontrakt splňuje tuto formální specifikaci. Kontrola modelu využívá prozkoumávání stavového prostoru, což zahrnuje konstrukci všech možných stavů chytrého kontraktu a pokus o nalezení dosažitelných stavů, které vedou k porušení chtěných vlastností. To však může vést k nekonečnému počtu stavů (známému jako „problém explozí stavů“), proto se při kontrole modelu spoléhejte na abstrakční techniky, které umožňují efektivní analýzu chytrých kontraktů. -### Dokazování vět {#theorem-proving} +### Dokazování teorémů {#theorem-proving} Dokazování věz je metoda matematického uvažování o správnosti programů, včetně chytrých kontraktů. Spočívá v transformaci modelu systému kontraktu a jeho specifikací na matematické formule (logické výroky). -Cílem dokazování vět je ověřit logickou ekvivalenci mezi těmito výroky. „Logická ekvivalence“ (také nazývaná „obousměrná logická implikace“) je typ vztahu mezi dvěma výroky, kdy první výrok je pravdivý, _pokud a jen pokud_ je pravdivý i druhý výrok. +Cílem dokazování vět je ověřit logickou ekvivalenci mezi těmito výroky. „Logická ekvivalence“ (také nazývaná „logická biimplikace“) je typ vztahu mezi dvěma výroky, kdy první výrok je pravdivý _právě tehdy, když_ je pravdivý i druhý výrok. Požadovaný vztah (logická ekvivalence) mezi výroky o modelu kontraktu a jeho vlastnostech je formulován jako dokazatelný výrok (nazývaný věta). Pomocí formálního systému odvozování může automatizovaný důkazní systém ověřit platnost této věty. Jinými slovy, důkazní systém může jednoznačně prokázat, že model chytrého kontraktu přesně odpovídá jeho specifikacím. @@ -130,13 +130,13 @@ V důsledku toho je často k vedení důkazního systému při odvozování důk ### Symbolické provádění {#symbolic-execution} -Symbolické provádění je metoda analýzy chytrých kontraktů, která provádí funkce pomocí _symbolických hodnot_ (např. `x > 5`) místo _konkrétních hodnot_ (např. `x == 5`). Jako technika formální verifikace se symbolické provádění používá k formálnímu uvažování o vlastnostech na úrovni tras v kódu kontraktu. +Symbolické provádění je metoda analýzy chytrého kontraktu prováděním funkcí s použitím _symbolických hodnot_ (např. `x > 5`) namísto _konkrétních hodnot_ (např. `x == 5`). Jako technika formální verifikace se symbolické provádění používá k formálnímu uvažování o vlastnostech na úrovni tras v kódu kontraktu. -Symbolické provádění reprezentuje trasu provádění jako matematický vzorec nad symbolickými vstupními hodnotami, které se jinak nazývají _predikát cesty_. K ověření, zda je predikát cesty „splnitelný“ (tj. zda existuje hodnota, která může vzorec splnit), se používá [SMT solver](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories). Pokud je zranitelná trasa splnitelná, SMT solver vygeneruje konkrétní hodnotu, která nasměruje provádění směrem k této trase. +Symbolické provádění představuje trasování provádění jako matematický vzorec nad symbolickými vstupními hodnotami, jinak nazývaný _predikát cesty_. [SMT solver](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) se používá ke kontrole, zda je predikát cesty „splnitelný“ (tj. zda existuje hodnota, která může splnit vzorec). Pokud je zranitelná trasa splnitelná, SMT solver vygeneruje konkrétní hodnotu, která nasměruje provádění směrem k této trase. -Předpokládejme, že funkce chytrého kontraktu přijímá jako vstup hodnotu typu `uint` (`x`) a vrací chybu, když je `x` větší než `5` a zároveň menší než `10`. Nalezení hodnoty pro `x`, která vyvolá chybu, by pomocí běžného testovacího postupu vyžadovalo provedení desítek testovacích případů (nebo více) bez záruky, že skutečně najdete vstup, který chybu vyvolá. +Předpokládejme, že funkce chytrého kontraktu přijímá jako vstup hodnotu typu `uint` (`x`) a vrátí se zpět, když je `x` větší než `5` a zároveň menší než `10`. Nalezení hodnoty `x`, která spustí chybu, by při běžném testovacím postupu vyžadovalo projít desítky testovacích případů (nebo více), aniž by byla zaručena skutečná nalezení vstupu, který chybu spouští. -Naopak, nástroj pro symbolické provádění by funkci spustil se symbolickou hodnotou: `X > 5 ∧ X < 10` (tj. `x` je větší než 5 A `x` je menší než 10). Příslušný predikát cesty `x = X > 5 ∧ X < 10` by byl poté zadán SMT solveru k vyřešení. Pokud nějaká hodnota splňuje vzorec `x = X > 5 ∧ X < 10`, SMT solver ji vypočítá – například solver může pro `x` vygenerovat hodnotu `7`. +Naopak, nástroj pro symbolické provádění by funkci provedl se symbolickou hodnotou: `X > 5 ∧ X < 10` (tj. `x` je větší než 5 A ZÁROVEŇ `x` je menší než 10). Přidružený predikát cesty `x = X > 5 ∧ X < 10` by pak byl předán SMT solveru k vyřešení. Pokud konkrétní hodnota splňuje vzorec `x = X > 5 ∧ X < 10`, SMT solver ji vypočítá – například může pro `x` vytvořit hodnotu `7`. Protože se symbolické provádění spoléhá na vstupy programu a množina vstupů pro prozkoumání všech dosažitelných stavů je potenciálně nekonečná, stále se jedná o formu testování. Jak však ukazuje příklad, symbolické provádění je efektivnější než běžné testování pro hledání vstupů, které vyvolávají porušení vlastností. @@ -152,29 +152,30 @@ function safe_add(uint x, uint y) returns(uint z){ require(z>=y); return z; +} ``` -Trasování provádění, které vede k přetečení celého čísla, by muselo splňovat vzorec: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)` Takový vzorec je nepravděpodobný k vyřešení, slouží tedy jako matematický důkaz, že funkce `safe_add` nikdy nepřeteče. +Trasování provádění, které má za následek celočíselné přetečení, by muselo splňovat vzorec: `z = x + y AND (z >= x) AND (z >= y) AND (z < x OR z < y)`. Takový vzorec je nepravděpodobné vyřešit, proto slouží jako matematický důkaz, že funkce `safe_add` nikdy nepřeteče. -### Proč používat formální ověřování pro chytré kontrakty? {#benefits-of-formal-verification} +### Proč používat formální ověřování pro chytré kontrakty? Výhody formálního ověření {#benefits-of-formal-verification} #### Potřeba spolehlivosti {#need-for-reliability} -Formální ověřování se používá k posouzení správnosti systémů kritických z hlediska bezpečnosti, jejichž selhání může mít katastrofální následky, jako je smrt, zranění nebo finanční krach. Chytré kontrakty jsou aplikace s vysokou hodnotou, které ovládají obrovské množství hodnot, a jednoduché chyby v návrhu mohou vést k [nezvratným ztrátám pro uživatele](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). Formální ověření kontraktu před jeho nasazením však může zvýšit záruku, že bude po spuštění na blockchainu fungovat dle očekávání. +Formální ověřování se používá k posouzení správnosti systémů kritických z hlediska bezpečnosti, jejichž selhání může mít katastrofální následky, jako je smrt, zranění nebo finanční krach. Chytré kontrakty jsou vysoce hodnotné aplikace, které ovládají obrovské množství hodnot, a jednoduché chyby v návrhu mohou vést k [nenávratným ztrátám pro uživatele](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). Formální ověření kontraktu před jeho nasazením však může zvýšit záruku, že bude po spuštění na blockchainu fungovat dle očekávání. Spolehlivost je velmi žádaná vlastnost každého chytrého kontraktu, zejména proto, že kód nasazený ve virtuálním stroji Etherea (EVM) je obvykle neměnný. Vzhledem k tomu, že aktualizace po spuštění nejsou snadno dostupné, je nutné zaručit spolehlivost kontraktu a provést formální ověření. Formální ověřování dokáže odhalit záludné problémy, jako je přetečení a podtečení integerů, reentrace a špatná optimalizace paliva, které mohou auditorům a testerům uniknout. -#### Prokázání funkční správnosti {#prove-functional-correctness} +#### Důkaz funkční správnosti {#prove-functional-correctness} Testování programu je nejběžnější metodou, jak prokázat, že chytrý kontrakt splňuje určité požadavky. To zahrnuje spuštění kontraktu se vzorkem dat, která má zpracovávat, a analýzu jeho chování. Pokud kontrakt vrátí očekávané výsledky pro vzorová data, mají vývojáři objektivní důkaz jeho správnosti. -Tento přístup však nemůže prokázat správné provedení pro vstupní hodnoty, které nejsou součástí vzorku. Proto testování kontraktu může pomoci odhalit chyby (tj. pokud některé cesty kódu nevracejí během provádění požadované výsledky), ale **nemůže jednoznačně prokázat neexistenci chyb**. +Tento přístup však nemůže prokázat správné provedení pro vstupní hodnoty, které nejsou součástí vzorku. Testování kontraktu proto může pomoci odhalit chyby (tj. pokud některé cesty kódu během provádění nevrátí požadované výsledky), ale **nemůže nezvratně prokázat nepřítomnost chyb**. -Naopak formální ověřování může formálně dokázat, že chytrý kontrakt splňuje požadavky pro nekonečný rozsah provedení _bez toho_, aby se kontrakt vůbec spustil. To vyžaduje vytvoření formální specifikace, která přesně popisuje správné chování kontraktu, a vytvoření formálního (matematického) modelu systému kontraktu. Poté můžeme formálním důkazním postupem zkontrolovat soulad mezi modelem kontraktu a jeho specifikací. +Naopak, formální ověření může formálně prokázat, že chytrý kontrakt splňuje požadavky pro nekonečný rozsah provádění, _aniž_ by se kontrakt vůbec spouštěl. To vyžaduje vytvoření formální specifikace, která přesně popisuje správné chování kontraktu, a vytvoření formálního (matematického) modelu systému kontraktu. Poté můžeme formálním důkazním postupem zkontrolovat soulad mezi modelem kontraktu a jeho specifikací. Při formálním ověřování je otázka ověření, zda obchodní logika kontraktu splňuje požadavky, matematickým tvrzením, které lze dokázat nebo vyvrátit. Formálním dokazováním tvrzení můžeme ověřit nekonečný počet testovacích případů s konečným počtem kroků. Tímto způsobem má formální ověření lepší vyhlídky prokázat, že kontrakt je funkčně shodný se specifikací. -#### Ideální cíle ověřování {#ideal-verification-targets} +#### Ideální cíle ověření {#ideal-verification-targets} Cíl ověřování popisuje systém, který má být formálně ověřen. Formální ověřování se nejlépe používá ve „vestavěných systémech“ (malých, jednoduchých částech softwaru, které jsou součástí většího systému). Jsou také ideální pro specializované domény, které mají málo pravidel, protože to usnadňuje úpravu nástrojů pro ověřování vlastností specifických pro danou doménu. @@ -182,15 +183,15 @@ Chytré kontrakty – alespoň do určité míry – splňují oba požadavky. N ### Rychlejší vývojový cyklus {#faster-development-cycle} -Techniky formálního ověřování, jako je kontrola modelu a symbolické provádění, jsou obecně účinnější než běžná analýza kódu chytrých kontraktů (prováděná během testování nebo auditu). Je to proto, že formální ověřování se při testování tvrzení spoléhá na symbolické hodnoty („co když se uživatel pokusí vybrat _n_ etheru?“) na rozdíl od testování, které používá konkrétní hodnoty („co když se uživatel pokusí vybrat 5 etheru?“). +Techniky formálního ověřování, jako je kontrola modelu a symbolické provádění, jsou obecně účinnější než běžná analýza kódu chytrých kontraktů (prováděná během testování nebo auditu). Je to proto, že formální ověření se spoléhá na symbolické hodnoty pro testování tvrzení („co když se uživatel pokusí vybrat _n_ etheru?“) na rozdíl od testování, které používá konkrétní hodnoty („co když se uživatel pokusí vybrat 5 etheru?“). Symbolické vstupní proměnné mohou pokrývat více tříd konkrétních hodnot, takže formální ověřovací přístupy slibují větší pokrytí kódu v kratším časovém horizontu. Pokud se formální ověřování používá efektivně, může vývojářům urychlit vývojový cyklus. Formální ověřování také zlepšuje proces vytváření decentralizovaných aplikací (dappek) tím, že omezuje nákladné chyby v návrhu. Aktualizace kontraktů (tam, kde je to možné) za účelem opravy zranitelností vyžaduje rozsáhlé přepisování kódových základen a větší úsilí vynaložené na vývoj. Formální ověřování může odhalit mnoho chyb v implementacích kontraktů, které mohou testerům a auditorům uniknout, a poskytuje dostatek příležitostí k jejich odstranění před nasazením kontraktu. -## Nevýhody formálního ověřování {#drawbacks-of-formal-verification} +## Nevýhody formálního ověření {#drawbacks-of-formal-verification} -### Náklady na ruční práci {#cost-of-manual-labor} +### Náklady na manuální práci {#cost-of-manual-labor} Formální ověřování, zejména poloautomatické ověřování, při němž člověk vede dokazovací nástroj při odvozování důkazů správnosti, vyžaduje značné množství ruční práce. Tvorba formální specifikace je navíc složitá činnost, která vyžaduje vysokou úroveň dovedností. @@ -202,82 +203,82 @@ Formální ověřování může pouze zkontrolovat, zda provedení chytrého kon Pokud jsou specifikace špatně napsané, porušení vlastností, které poukazují na zranitelná provedení, nelze při auditu formálního ověřování odhalit. V takovém případě by se vývojář mohl mylně domnívat, že kontrakt je bez chyb. -### Výkonnostní problémy {#performance-issues} +### Problémy s výkonem {#performance-issues} Formální ověřování naráží na řadu výkonnostních problémů. Například problémy s explozí stavů a cest, které se vyskytují při kontrole modelu, resp. symbolické kontrole, mohou ovlivnit verifikační postupy. Dále formální ověřovací nástroje často používají ve své základní vrstvě SMT řešiče a jiné řešiče omezení a ty se spoléhají na výpočetně náročné postupy. -Také není vždy možné, aby ověřovatelé programů určili, zda je vlastnost (popsaná jako logická formule) splnitelná nebo ne („problém [rozhodnutelnosti](https://en.wikipedia.org/wiki/Decision_problem)“), protože program nemusí být nikdy ukončen. Proto může být nemožné prokázat některé vlastnosti kontraktu, i když je dobře specifikovaný. +Také není vždy možné, aby ověřovatelé programů určili, zda je vlastnost (popsaná jako logická formule) splnitelná nebo ne („[problém rozhodnutelnosti](https://en.wikipedia.org/wiki/Decision_problem)“), protože program nemusí být nikdy ukončen. Proto může být nemožné prokázat některé vlastnosti kontraktu, i když je dobře specifikovaný. -## Nástroje pro formální ověřování chytrých kontraktů na Ethereu {#formal-verification-tools} +## Nástroje pro formální ověření chytrých kontraktů na Ethereu {#formal-verification-tools} ### Specifikační jazyky pro vytváření formálních specifikací {#specification-languages} -**Act** – _*Act umožňuje specifikovat aktualizace úložiště, předběžné/následné podmínky a invarianty kontraktu. Jeho sada nástrojů má také dokazovací backendy, které dokáží dokázat mnoho vlastností pomocí Coq, SMT solverů nebo hevm.** +**Act**: __Act umožňuje specifikaci aktualizací úložiště, vstupních/výstupních podmínek a invariantů kontraktu._ Jeho sada nástrojů má také dokazovací backendy, které dokáží dokázat mnoho vlastností pomocí Coq, SMT solverů nebo hevm.\*_ - [GitHub](https://github.com/ethereum/act) -- [Dokumentace](https://ethereum.github.io/act/) +- [Dokumentace](https://github.com/argotorg/act) -**Scribble** – _*Scribble transformuje anotace kódu ve specifikačním jazyce Scribble na konkrétní tvrzení, která kontrolují specifikaci.** +**Scribble** - __Scribble transformuje anotace v kódu ve specifikačním jazyce Scribble do konkrétních tvrzení, která kontrolují specifikaci.__ - [Dokumentace](https://docs.scribble.codes/) -**Dafny** – _*Dafny je programovací jazyk připravený na ověřování, který se spoléhá na vysokoúrovňové anotace pro zdůvodnění a prokázání správnosti kódu.** +**Dafny** - __Dafny je programovací jazyk připravený na ověřování, který se spoléhá na vysokoúrovňové anotace pro zdůvodnění a prokázání správnosti kódu.__ - [GitHub](https://github.com/dafny-lang/dafny) ### Ověřovače programů pro kontrolu správnosti {#program-verifiers} -**Certora Prover** – _Certora Prover je automatický formální ověřovací nástroj pro kontrolu správnosti kódu v chytrých kontraktech. Specifikace jsou napsány v jazyce CVL (Certora Verification Language), přičemž porušení vlastností se zjišťuje pomocí kombinace statické analýzy a řešení omezení._ +**Certora Prover** - _Certora Prover je automatický nástroj pro formální ověření, který kontroluje správnost kódu v chytrých kontraktech. Specifikace jsou napsány v jazyce CVL (Certora Verification Language), přičemž porušení vlastností se zjišťuje pomocí kombinace statické analýzy a řešení omezení._ -- [Web](https://www.certora.com/) +- [Webové stránky](https://www.certora.com/) - [Dokumentace](https://docs.certora.com/en/latest/index.html) -**Solidity SMTChecker** – _*Solidity SMTChecker je vestavěný ověřovač modelu založený na SMT (Satisfiability Modulo Theories) a Hornově řešení. Během kompilace potvrzuje, zda zdrojový kód kontraktu odpovídá specifikacím, a staticky kontroluje, zda nejsou porušeny bezpečnostní vlastnosti.** +**Solidity SMTChecker** - __SMTChecker v Solidity je vestavěný nástroj pro kontrolu modelů založený na SMT (Satisfiability Modulo Theories) a Hornově řešení._ Během kompilace potvrzuje, zda zdrojový kód kontraktu odpovídá specifikacím, a staticky kontroluje, zda nejsou porušeny bezpečnostní vlastnosti.\*_ - [GitHub](https://github.com/ethereum/solidity) -**solc-verify** – _*solc-verify je rozšířená verze kompilátoru Solidity, která dokáže provádět automatické formální ověřování kódu Solidity pomocí anotací a modulárního ověřování programu.** +**solc-verify** - __solc-verify je rozšířená verze kompilátoru Solidity, která dokáže provádět automatické formální ověřování kódu v Solidity pomocí anotací a modulárního ověřování programů.__ - [GitHub](https://github.com/SRI-CSL/solidity) -**KEVM** – _*KEVM je formální sémantika virtuálního stroje Etherea (EVM) napsaná ve frameworku K. KEVM je spustitelný a může dokazovat určitá tvrzení týkající se vlastností pomocí logiky dosažitelnosti.** +**KEVM** - __KEVM je formální sémantika Ethereum Virtual Machine (EVM) napsaná v K frameworku._ KEVM je spustitelný a může dokazovat určitá tvrzení týkající se vlastností pomocí logiky dosažitelnosti.\*_ - [GitHub](https://github.com/runtimeverification/evm-semantics) - [Dokumentace](https://jellopaper.org/) -### Logické frameworky pro dokazování tvrzení {#theorem-provers} +### Logické frameworky pro dokazování teorémů {#theorem-provers} -**Isabelle** – _Isabelle/HOL je dokazovací pomocník, který umožňuje vyjádřit matematické formule ve formálním jazyce a poskytuje nástroje pro dokazování těchto formulí. Hlavní aplikací je formalizace matematických důkazů a zejména formální ověřování, které zahrnuje dokazování správnosti počítačového hardwaru nebo softwaru a dokazování vlastností počítačových jazyků a protokolů._ +**Isabelle** - _Isabelle/HOL je dokazovací asistent, který umožňuje vyjádřit matematické formule ve formálním jazyce a poskytuje nástroje pro dokazování těchto formulí. Hlavní aplikací je formalizace matematických důkazů a zejména formální ověřování, které zahrnuje dokazování správnosti počítačového hardwaru nebo softwaru a dokazování vlastností počítačových jazyků a protokolů._ - [GitHub](https://github.com/isabelle-prover) - [Dokumentace](https://isabelle.in.tum.de/documentation.html) -**Coq** – _Coq je interaktivní dokazovací nástroj, který umožňuje definovat programy pomocí vět a interaktivně generovat strojově kontrolované důkazy správnosti._ +**Rocq** - _Rocq je interaktivní dokazovač teorémů, který umožňuje definovat programy pomocí teorémů a interaktivně generovat strojově kontrolované důkazy správnosti._ -- [GitHub](https://github.com/coq/coq) -- [Dokumentace](https://coq.github.io/doc/v8.13/refman/index.html) +- [GitHub](https://github.com/rocq-prover/rocq) +- [Dokumentace](https://rocq-prover.org/docs) -### Nástroje pro odhalování zranitelných vzorů v chytrých kontraktech založené na symbolickém provádění {#symbolic-execution-tools} +### Nástroje založené na symbolickém provádění pro detekci zranitelných vzorů v chytrých kontraktech {#symbolic-execution-tools} -**Manticore** – _*Nástroj pro analýzu bytekódu EVM založený na symbolickém provádění*.* +**Manticore** - __Nástroj pro analýzu bajtkódu EVM založený na symbolickém provádění_._ - [GitHub](https://github.com/trailofbits/manticore) - [Dokumentace](https://github.com/trailofbits/manticore/wiki) -**hevm** – _*hevm je nástroj pro symbolické provádění a kontrolu ekvivalence pro bytekód EVM.** +**hevm** - __hevm je nástroj pro symbolické provádění a kontrolu ekvivalence pro bajtkód EVM.__ - [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) -**Mythril** – _Nástroj pro symbolické provádění k odhalování zranitelností v chytrých kontraktech Etherea._ +**Mythril** - _Nástroj pro symbolické provádění k odhalování zranitelností v chytrých kontraktech Etherea_ - [GitHub](https://github.com/ConsenSys/mythril-classic) - [Dokumentace](https://mythril-classic.readthedocs.io/en/develop/) -## Další četba {#further-reading} +## Další čtení {#further-reading} -- [Jak funguje formální ověřování chytrých kontraktů](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) -- [Jak může formální ověřování zajistit bezchybné chytré kontrakty](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) -- [Přehled projektů formálního ověřování v ekosystému Etherea](https://github.com/leonardoalt/ethereum_formal_verification_overview) -- [Formální end-to-end ověřování chytrého kontraktu Ethereum 2.0 Deposit Smart Contract](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [Jak funguje formální ověření chytrých kontraktů](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [Jak může formální ověření zajistit bezchybné chytré kontrakty](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [Přehled projektů formálního ověření v ekosystému Etherea](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [End-to-end formální ověření chytrého kontraktu pro vklad na Ethereum 2.0](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) - [Formální ověření nejoblíbenějšího chytrého kontraktu na světě](https://www.zellic.io/blog/formal-verification-weth) -- [SMTChecker a formální ověřování](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) +- [SMTChecker a formální ověření](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/index.md b/public/content/translations/cs/developers/docs/smart-contracts/index.md index 1608d0dd257..67258b9d659 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/index.md @@ -1,29 +1,29 @@ --- -title: Úvod do smart kontraktů -description: Přehled smart kontraktů se zaměřením na jejich jedinečné vlastnosti a omezení. +title: "Úvod do smart kontraktů" +description: "Přehled smart kontraktů se zaměřením na jejich jedinečné vlastnosti a omezení." lang: cs --- -## Co to je smart kontrakt? {#what-is-a-smart-contract} +## Co je to smart kontrakt? {#what-is-a-smart-contract} „Smart kontrakt“ je jednoduše program, který je spuštěn na blockchainu Ethereum. Je to sbírka kódu (jeho funkcí) a dat (jeho stavu), které sídlí na specifické adrese na blockchainu Ethereum. -Smart kontrakty jsou typem [účtu na Ethereu](/developers/docs/accounts/). To znamená, že mají zůstatek a mohou být cílem transakcí. Nejsou však ovládány uživatelem, místo toho jsou nasazeny na síť a běží podle toho, jak jsou naprogramovány. Uživatelé pak mohou interagovat se smart kontraktem prostřednictvím transakcí, které spouštějí funkce definované na smart kontraktu. Smart kontrakty mohou definovat pravidla, podobně jako běžné smlouvy, a automaticky je vynucovat prostřednictvím kódu. Smart kontrakty nelze ve výchozím nastavení smazat a interakce s nimi jsou nevratné. +Chytré kontrakty jsou typem [účtu na Ethereu](/developers/docs/accounts/). To znamená, že mají zůstatek a mohou být cílem transakcí. Nejsou však ovládány uživatelem, místo toho jsou nasazeny na síť a běží podle toho, jak jsou naprogramovány. Uživatelé pak mohou interagovat se smart kontraktem prostřednictvím transakcí, které spouštějí funkce definované na smart kontraktu. Smart kontrakty mohou definovat pravidla, podobně jako běžné smlouvy, a automaticky je vynucovat prostřednictvím kódu. Smart kontrakty nelze ve výchozím nastavení smazat a interakce s nimi jsou nevratné. ## Předpoklady {#prerequisites} -Pokud teprve začínáte nebo hledáte méně technický úvod, doporučujeme si přečíst naši [úvodní příručku ke smart kontraktům](/smart-contracts/). +Pokud teprve začínáte nebo hledáte méně technický úvod, doporučujeme naši [úvodní příručku k chytrým kontraktům](/smart-contracts/). -Ujistěte se, že jste si přečetli informace o [účtech](/developers/docs/accounts/), [transakcích](/developers/docs/transactions/) a [Virtuálním stroji Etherea](/developers/docs/evm/), než se pustíte do světa smart kontraktů. +Než se pustíte do světa chytrých kontraktů, přečtěte si o [účtech](/developers/docs/accounts/), [transakcích](/developers/docs/transactions/) a [Ethereum Virtual Machine (EVM)](/developers/docs/evm/). -## Digitální výdejní automat {#a-digital-vending-machine} +## Digitální prodejní automat {#a-digital-vending-machine} -Možná nejlepší metaforou pro smart kontrakt je výdejní automat, jak jej popsal [Nick Szabo](https://unenumerated.blogspot.com/). S těmi správnými vstupy je zaručen určitý výstup. +Možná nejlepší metaforou pro chytrý kontrakt je prodejní automat, jak ho popsal [Nick Szabo](https://unenumerated.blogspot.com/). S těmi správnými vstupy je zaručen určitý výstup. Pakliže chcete svačinu z prodejního automatu: ``` -money + snack selection = snack dispensed +peníze + výběr občerstvení = vydané občerstvení ``` Tato logika je naprogramována do automatu. @@ -35,25 +35,25 @@ pragma solidity 0.8.7; contract VendingMachine { - // Declare state variables of the contract + // Deklarace stavových proměnných kontraktu address public owner; mapping (address => uint) public cupcakeBalances; - // When 'VendingMachine' contract is deployed: - // 1. set the deploying address as the owner of the contract - // 2. set the deployed smart contract's cupcake balance to 100 + // Když je kontrakt 'VendingMachine' nasazen: + // 1. nastaví adresu nasazujícího jako vlastníka kontraktu + // 2. nastaví zůstatek cupcake v nasazeném chytrém kontraktu na 100 constructor() { owner = msg.sender; cupcakeBalances[address(this)] = 100; } - // Allow the owner to increase the smart contract's cupcake balance + // Umožní vlastníkovi navýšit zůstatek cupcake v chytrém kontraktu function refill(uint amount) public { require(msg.sender == owner, "Only the owner can refill."); cupcakeBalances[address(this)] += amount; } - // Allow anyone to purchase cupcakes + // Umožní komukoliv zakoupit cupcake function purchase(uint amount) public payable { require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); @@ -65,48 +65,48 @@ contract VendingMachine { Podobně jako prodejní automat odstraňuje potřebu zaměstnance prodejce, smart kontrakty mohou nahradit prostředníky v mnoha průmyslových odvětvích. -## Bez nutnosti povolení {#permissionless} +## Bez povolení {#permissionless} -Kdokoli může napsat smart kontrakt a vypustit ho na síť. Stačí se naučit programovat v [jazyce pro smart kontrakty](/developers/docs/smart-contracts/languages/) a mít dostatek ETH k nasazení kontraktu. Nasazení smart kontraktu je z technického hlediska transakcí, takže musíte zaplatit poplatek za [palivo](/developers/docs/gas/), stejně jako při jednoduchém převodu ETH. Náklady na palivo jsou však při nasazení kontraktu mnohem vyšší. +Kdokoli může napsat smart kontrakt a vypustit ho na síť. Stačí se naučit programovat v [jazyce pro chytré kontrakty](/developers/docs/smart-contracts/languages/) a mít dostatek ETH k nasazení vašeho kontraktu. Nasazení chytrého kontraktu je technicky transakce, takže musíte zaplatit [gas](/developers/docs/gas/) stejným způsobem, jako platíte gas za jednoduchý převod ETH. Náklady na palivo jsou však při nasazení kontraktu mnohem vyšší. Ethereum má programovací jazyky pro psaní smart kontraktů, které jsou vývojářsky přívětivé: - Solidity - Vyper -[Další informace o jazycích](/developers/docs/smart-contracts/languages/) +[Více o jazycích](/developers/docs/smart-contracts/languages/) -Je však třeba je před nasazením zkompilovat, aby je Virtuální stroj Etherea mohl interpretovat a uložit. [Více informací o kompilaci](/developers/docs/smart-contracts/compiling/) +Je však třeba je před nasazením zkompilovat, aby je Virtuální stroj Etherea mohl interpretovat a uložit. [Více o kompilaci](/developers/docs/smart-contracts/compiling/) ## Složitelnost {#composability} Chytré kontrakty na Ethereu jsou veřejné a lze je považovat za otevřená API. To znamená, že ve svém smart kontraktu můžete volat jiné smart kontrakty, což značně rozšiřuje vaše možnosti. Kontrakty mohou dokonce nasazovat další kontrakty. -Další informace o [komponovatelnosti smart kontraktů](/developers/docs/smart-contracts/composability/). +Zjistěte více o [složitelnosti chytrých kontraktů](/developers/docs/smart-contracts/composability/). ## Omezení {#limitations} Samotné chytré kontrakty nemohou získávat informace o „skutečných“ událostech, protože nemohou získávat data ze zdrojů mimo blockchain. To znamená, že nemohou reagovat na události ve skutečném světě. Tento design je úmyslný. Spoléhat se na externí informace by mohlo ohrozit konsenzus, což je důležité pro bezpečnost a decentralizaci. -Nicméně je důležité, aby blockchainové aplikace mohly používat data, která jsou mimo blockchain. Řešením jsou [orákula](/developers/docs/oracles/), což jsou nástroje, které zpracovávají data mimo blockchain a zpřístupňují je chytrým kontraktům. +Nicméně je důležité, aby blockchainové aplikace mohly používat data, která jsou mimo blockchain. Řešením jsou [orákula](/developers/docs/oracles/), což jsou nástroje, které přijímají data mimo blockchain a zpřístupňují je chytrým kontraktům. -Dalším omezením smart kontraktů je maximální velikost kontraktu. Smart kontrakt může mít maximálně 24 Kb, jinak dojde k vyčerpání paliva. Toto lze obejít pomocí tzv. [Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535). +Dalším omezením smart kontraktů je maximální velikost kontraktu. Smart kontrakt může mít maximálně 24 Kb, jinak dojde k vyčerpání paliva. Tomu se lze vyhnout použitím [The Diamond Pattern](https://eips.ethereum.org/EIPS/eip-2535). ## Multisig kontrakty {#multisig} -Multisig (vícepodpisové) kontrakty jsou smart kontraktové účty, které vyžadují více platných podpisů k provedení transakce. To je velmi užitečné pro zabránění jednotlivým bodům selhání u kontraktů držících značné množství etheru nebo jiných tokenů. Multisigy také mohou rozdělit odpovědnost za provádění kontraktů a správu klíčů mezi více stran a zabraňují ztrátě prostředků v případě ztráty jediného soukromého klíče. Z těchto důvodů lze multisig kontrakty použít pro jednoduchou správu DAO. Multisigy vyžadují N podpisů z M možných přijatelných podpisů (kde N ≤ M a M > 1) k provedení transakce. Běžně se používají multisigy `N = 3, M = 5` a `N = 4, M = 7`. Multisig 4/7 vyžaduje čtyři ze sedmi možných platných podpisů. To znamená, že prostředky jsou stále dostupné, i když jsou ztraceny tři podpisy. V tomto případě to také znamená, že většina držitelů klíčů musí souhlasit a podepsat, aby mohl být kontrakt exekuován. +Multisig (vícepodpisové) kontrakty jsou smart kontraktové účty, které vyžadují více platných podpisů k provedení transakce. To je velmi užitečné pro zabránění jednotlivým bodům selhání u kontraktů držících značné množství etheru nebo jiných tokenů. Multisigy také mohou rozdělit odpovědnost za provádění kontraktů a správu klíčů mezi více stran a zabraňují ztrátě prostředků v případě ztráty jediného soukromého klíče. Z těchto důvodů lze multisig kontrakty použít pro jednoduchou správu DAO. Multisigy vyžadují N podpisů z M možných přijatelných podpisů (kde N ≤ M a M > 1) k provedení. Běžně se používají hodnoty `N = 3, M = 5` a `N = 4, M = 7`. Multisig 4/7 vyžaduje čtyři ze sedmi možných platných podpisů. To znamená, že prostředky jsou stále dostupné, i když jsou ztraceny tři podpisy. V tomto případě to také znamená, že většina držitelů klíčů musí souhlasit a podepsat, aby mohl být kontrakt exekuován. -## Zdroje smart kontraktů {#smart-contract-resources} +## Zdroje k chytrým kontraktům {#smart-contract-resources} -**OpenZeppelin Contracts –** **_knihovna pro vývoj bezpečných chytrých kontraktů._** +**OpenZeppelin Contracts -** **_Knihovna pro bezpečný vývoj chytrých kontraktů._** - [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [Komunitní fórum](https://forum.openzeppelin.com/c/general/16) -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Coinbase: Co je to smart kontrakt?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) -- [Chainlink: Co je to smart kontrakt?](https://chain.link/education/smart-contracts) -- [Video: Simply Explained – Smart Contracts](https://youtu.be/ZE2HxTmxfrI) -- [Cyfrin Updraft: Web3 learning and auditing platform](https://updraft.cyfrin.io) +- [Coinbase: Co je to chytrý kontrakt?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink: Co je to chytrý kontrakt?](https://chain.link/education/smart-contracts) +- [Video: Jednoduše vysvětleno – Chytré kontrakty](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: Web3 výuková a auditovací platforma](https://updraft.cyfrin.io) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md b/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md index 7ba4c3e0b6f..9a07c8a1922 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md @@ -1,25 +1,25 @@ --- -title: Jazyk chytrých smluv -description: Přehled a srovnání dvou hlavních programovacích jazyků pro smart kontrakty – Solidity a Vyper. +title: "Jazyk chytrých kontraktů" +description: "Přehled a srovnání dvou hlavních programovacích jazyků pro smart kontrakty – Solidity a Vyper." lang: cs --- -Jednou z výhod Etherea je, že smart kontrakty lze programovat v relativně uživatelsky přívětivých programovacích jazycích. Pokud máte zkušenosti s Pythonem nebo jiným [jazykem používajícím složené závorky](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), můžete si najít jazyk s podobnou syntaxí. +Jednou z výhod Etherea je, že smart kontrakty lze programovat v relativně uživatelsky přívětivých programovacích jazycích. Pokud máte zkušenosti s Pythonem nebo jakýmkoli [jazykem se složenými závorkami](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), můžete najít jazyk se známou syntaxí. Dva nejaktivnější a nejvíce udržované jazyky jsou: - Solidity - Vyper -Remix IDE poskytuje komplexní vývojové prostředí pro vytváření a testování kontraktů jak v Solidity, tak ve Vyperu. [Vyzkoušejte webový Remix IDE](https://remix.ethereum.org), abyste mohli začít kódovat. +Remix IDE poskytuje komplexní vývojové prostředí pro vytváření a testování kontraktů jak v Solidity, tak ve Vyperu. [Vyzkoušejte Remix IDE v prohlížeči](https://remix.ethereum.org) a začněte kódovat. -Zkušenější vývojáři mohou také chtít používat Yul, což je intermediární jazyk pro [Virtuální stroj Etherea](/developers/docs/evm/), nebo Yul+, rozšíření jazyka Yul. +Zkušenější vývojáři mohou také chtít používat Yul, což je přechodný jazyk pro [Ethereum Virtual Machine](/developers/docs/evm/), nebo Yul+, rozšíření jazyka Yul. Pokud jste zvědaví a rádi pomáháte testovat nové jazyky, které jsou stále ve fázi intenzivního vývoje, můžete experimentovat s Fe, nově vznikajícím jazykem pro smart kontrakty, který je v současnosti ještě v rané fázi. ## Předpoklady {#prerequisites} -Předchozí znalosti programovacích jazyků, zejména JavaScriptu nebo Pythonu, vám mohou pomoci lépe porozumět rozdílům mezi jazyky pro smart kontrakty. Doporučujeme také, abyste nejprve pochopili koncept smart kontraktů, než se ponoříte do srovnání jazyků. [Úvod do smart kontraktů](/developers/docs/smart-contracts/). +Předchozí znalosti programovacích jazyků, zejména JavaScriptu nebo Pythonu, vám mohou pomoci lépe porozumět rozdílům mezi jazyky pro smart kontrakty. Doporučujeme také, abyste nejprve pochopili koncept smart kontraktů, než se ponoříte do srovnání jazyků. [Úvod do chytrých kontraktů](/developers/docs/smart-contracts/). ## Solidity {#solidity} @@ -35,45 +35,45 @@ Předchozí znalosti programovacích jazyků, zejména JavaScriptu nebo Pythonu, - [Dokumentace](https://docs.soliditylang.org/en/latest/) - [Portál jazyka Solidity](https://soliditylang.org/) -- [Solidity by Example](https://docs.soliditylang.org/en/latest/solidity-by-example.html) +- [Příklady v Solidity](https://docs.soliditylang.org/en/latest/solidity-by-example.html) - [GitHub](https://github.com/ethereum/solidity/) -- [Solidity Gitter Chatroom](https://gitter.im/ethereum/solidity) propojeno se [Solidity Matrix Chatroom](https://matrix.to/#/#ethereum_solidity:gitter.im) +- [Diskusní místnost Solidity na Gitteru](https://gitter.im/ethereum/solidity) přemostěná do [diskusní místnosti Solidity na Matrixu](https://matrix.to/#/#ethereum_solidity:gitter.im) - [Tahák](https://reference.auditless.com/cheatsheet) - [Blog Solidity](https://blog.soliditylang.org/) -- [Twitter Solidity](https://twitter.com/solidity_lang) +- [Solidity na Twitteru](https://twitter.com/solidity_lang) -### Ukázkový kontrakt {#example-contract} +### Příklad kontraktu {#example-contract} ```solidity // SPDX-License-Identifier: GPL-3.0 pragma solidity >= 0.7.0; contract Coin { - // The keyword "public" makes variables - // accessible from other contracts + // Klíčové slovo "public" zpřístupňuje proměnné + // z ostatních kontraktů address public minter; mapping (address => uint) public balances; - // Events allow clients to react to specific - // contract changes you declare + // Události umožňují klientům reagovat na specifické + // změny kontraktu, které deklarujete event Sent(address from, address to, uint amount); - // Constructor code is only run when the contract - // is created + // Kód konstruktoru se spouští pouze při vytvoření + // kontraktu constructor() { minter = msg.sender; } - // Sends an amount of newly created coins to an address - // Can only be called by the contract creator + // Odešle množství nově vytvořených mincí na adresu + // Může být voláno pouze tvůrcem kontraktu function mint(address receiver, uint amount) public { require(msg.sender == minter); require(amount < 1e60); balances[receiver] += amount; } - // Sends an amount of existing coins - // from any caller to an address + // Odešle množství existujících mincí + // od jakéhokoli volajícího na adresu function send(address receiver, uint amount) public { require(amount <= balances[msg.sender], "Insufficient balance."); balances[msg.sender] -= amount; @@ -83,7 +83,7 @@ contract Coin { } ``` -Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontraktů v Solidity. Pro podrobnější popis funkcí a proměnných [si přečtěte dokumentaci](https://docs.soliditylang.org/en/latest/contracts.html). +Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontraktů v Solidity. Podrobnější popis funkcí a proměnných [naleznete v dokumentaci](https://docs.soliditylang.org/en/latest/contracts.html). ## Vyper {#vyper} @@ -93,7 +93,7 @@ Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontr - Efektivní generování bytekódu - Úmyslně má méně funkcí než Solidity s cílem učinit kontrakty bezpečnějšími a snáze auditovatelnými. Vyper nepodporuje: - Modifikátory - - #Dědičnost + - Dědičnost - Inline sestavení (assembly) - Přetěžování funkcí - Přetěžování operátorů @@ -101,110 +101,128 @@ Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontr - Nekonečné smyčky - Binární pevné body -Pro více informací si přečtěte [Vyper rationale](https://vyper.readthedocs.io/en/latest/index.html). +Pro více informací si [přečtěte Vyper rationale](https://vyper.readthedocs.io/en/latest/index.html). ### Důležité odkazy {#important-links-1} - [Dokumentace](https://vyper.readthedocs.io) -- [Vyper by Example](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) -- [More Vyper by Example](https://vyper-by-example.org/) +- [Příklady ve Vyperu](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) +- [Další příklady ve Vyperu](https://vyper-by-example.org/) - [GitHub](https://github.com/vyperlang/vyper) -- [Discord chat Vyper komunity](https://discord.gg/SdvKC79cJk) +- [Komunitní chat Vyperu na Discordu](https://discord.gg/SdvKC79cJk) - [Tahák](https://reference.auditless.com/cheatsheet) -- [Frameworky a nástroje pro vývoj smart kontraktů v jazyce Vyper](/developers/docs/programming-languages/python/) -- [VyperPunk – naučte se zabezpečit a hackovat smart kontrakty v jazyce Vyper](https://github.com/SupremacyTeam/VyperPunk) -- [Vyper Hub pro vývojáře](https://github.com/zcor/vyper-dev) -- [Příklady nejlepších chytrých kontraktů na Vyper](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) -- [Úžasné Vyperem kurátorované zdroje](https://github.com/spadebuilders/awesome-vyper) +- [Frameworky a nástroje pro vývoj chytrých kontraktů pro Vyper](/developers/docs/programming-languages/python/) +- [VyperPunk – naučte se zabezpečit a hackovat chytré kontrakty ve Vyperu](https://github.com/SupremacyTeam/VyperPunk) +- [Vyper Hub pro vývoj](https://github.com/zcor/vyper-dev) +- [Vyper – nejlepší příklady chytrých kontraktů](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [Awesome Vyper – vybrané zdroje](https://github.com/spadebuilders/awesome-vyper) ### Příklad {#example} ```python -# Open Auction +# Otevřená aukce + +# Parametry aukce + +# Příjemce obdrží peníze od nejvyššího nabízejícího -# Auction params -# Beneficiary receives money from the highest bidder beneficiary: public(address) auctionStart: public(uint256) auctionEnd: public(uint256) -# Current state of auction +# Aktuální stav aukce + highestBidder: public(address) highestBid: public(uint256) -# Set to true at the end, disallows any change +# Na konci se nastaví na true, zakáže jakoukoli změnu + ended: public(bool) -# Keep track of refunded bids so we can follow the withdraw pattern +# Sledujeme vrácené nabídky, abychom mohli použít vzor výběru + pendingReturns: public(HashMap[address, uint256]) -# Create a simple auction with `_bidding_time` -# seconds bidding time on behalf of the -# beneficiary address `_beneficiary`. +# Vytvoří jednoduchou aukci s `_bidding_time` + +# sekundami pro přihazování jménem + +# adresy příjemce `_beneficiary`. + @external def __init__(_beneficiary: address, _bidding_time: uint256): self.beneficiary = _beneficiary self.auctionStart = block.timestamp self.auctionEnd = self.auctionStart + _bidding_time -# Bid on the auction with the value sent -# together with this transaction. -# The value will only be refunded if the -# auction is not won. +# Přihodí do aukce s hodnotou zaslanou + +# spolu s touto transakcí. + +# Hodnota bude vrácena pouze v případě, + +# že aukce nebude vyhrána. + @external @payable def bid(): - # Check if bidding period is over. + # Zkontroluje, zda období pro přihazování skončilo. assert block.timestamp < self.auctionEnd - # Check if bid is high enough + # Zkontroluje, zda je nabídka dostatečně vysoká assert msg.value > self.highestBid - # Track the refund for the previous high bidder + # Sleduje vrácení peněz předchozímu nejvyššímu nabízejícímu self.pendingReturns[self.highestBidder] += self.highestBid - # Track new high bid + # Sleduje novou nejvyšší nabídku self.highestBidder = msg.sender self.highestBid = msg.value -# Withdraw a previously refunded bid. The withdraw pattern is -# used here to avoid a security issue. If refunds were directly -# sent as part of bid(), a malicious bidding contract could block -# those refunds and thus block new higher bids from coming in. +# Vybere dříve vrácenou nabídku. Vzor výběru (withdraw pattern) se + +# zde používá k zamezení bezpečnostního problému. Pokud by byly refundace přímo + +# odesílány jako součást bid(), mohl by škodlivý kontrakt blokovat + +# tyto refundace a tím zabránit příchodu nových vyšších nabídek. + @external def withdraw(): pending_amount: uint256 = self.pendingReturns[msg.sender] self.pendingReturns[msg.sender] = 0 send(msg.sender, pending_amount) -# End the auction and send the highest bid -# to the beneficiary. +# Ukončí aukci a pošle nejvyšší nabídku + +# příjemci. + @external def endAuction(): - # It is a good guideline to structure functions that interact - # with other contracts (i.e., they call functions or send ether) - # into three phases: - # 1. checking conditions - # 2. performing actions (potentially changing conditions) - # 3. interacting with other contracts - # If these phases are mixed up, the other contract could call - # back into the current contract and modify the state or cause - # effects (ether payout) to be performed multiple times. - # If functions called internally include interaction with external - # contracts, they also have to be considered interaction with - # external contracts. - - # 1. Conditions - # Check if auction endtime has been reached + # Je dobrým zvykem strukturovat funkce, které interagují + # s jinými kontrakty (tj. volají funkce nebo posílají ether), + # do tří fází: + # 1. kontrola podmínek + # 2. provádění akcí (potenciálně měnících podmínky) + # 3. interakce s jinými kontrakty + # Pokud jsou tyto fáze smíchány, jiný kontrakt by mohl volat + # zpět do aktuálního kontraktu a upravit stav nebo způsobit, + # že efekty (vyplacení etheru) budou provedeny vícekrát. + # Pokud interně volané funkce zahrnují interakci s externími + # kontrakty, musí být také považovány za interakci s + # externími kontrakty. + + # 1. Podmínky + # Zkontroluje, zda bylo dosaženo konce aukce assert block.timestamp >= self.auctionEnd - # Check if this function has already been called + # Zkontroluje, zda tato funkce již byla volána assert not self.ended - # 2. Effects + # 2. Efekty self.ended = True - # 3. Interaction + # 3. Interakce send(self.beneficiary, self.highestBid) ``` -Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontraktů ve Vyperu. Pro podrobnější popis funkcí a proměnných [si přečtěte dokumentaci](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction). +Tento příklad by vám měl poskytnout představu o tom, jaká je syntaxe kontraktů ve Vyperu. Podrobnější popis funkcí a proměnných [najdete v dokumentaci](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction). ## Yul a Yul+ {#yul} @@ -213,24 +231,25 @@ Pokud jste v Ethereum nováčkem a ještě jste neprogramovali v jazycích pro s **Yul** - Pokročilý jazyk pro Ethereum. -- Podporuje [EVM](/developers/docs/evm) i [Ewasm](https://github.com/ewasm), což je varianta WebAssembly přizpůsobená pro Ethereum, a je navržen tak, aby byl použitelným společným základem pro obě platformy. +- Podporuje [EVM](/developers/docs/evm) a [Ewasm](https://github.com/ewasm), což je varianta WebAssembly pro Ethereum, a je navržen tak, aby byl použitelným společným jmenovatelem obou platforem. - Dobrá volba pro optimalizační fáze na vyšší úrovni, které mohou mít stejný přínos jak pro platformy EVM, tak pro Ewasm. **Yul+** - Nízkoúrovňové, vysoce efektivní rozšíření Yulu. -- Původně navržen pro kontrakt [optimistického rollupu](/developers/docs/scaling/optimistic-rollups/). +- Původně navrženo pro kontrakt [optimistického rollupu](/developers/docs/scaling/optimistic-rollups/). - Yul+ lze považovat za experimentální návrh upgradu Yul, který do něj přidává nové funkce. ### Důležité odkazy {#important-links-2} - [Dokumentace Yul](https://docs.soliditylang.org/en/latest/yul.html) - [Dokumentace Yul+](https://github.com/fuellabs/yulp) -- [Úvodní příspěvek Yul+](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) +- [Úvodní příspěvek o Yul+](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) -### Ukázkový kontrakt {#example-contract-2} +### Příklad kontraktu {#example-contract-2} -Následující jednoduchý příklad implementuje funkci mocniny. Lze jej zkompilovat pomocí příkazu `solc --strict-assembly --bin input.yul`. Příklad by měl být uložen v souboru input.yul. +Následující jednoduchý příklad implementuje funkci mocniny. Lze jej zkompilovat pomocí `solc --strict-assembly --bin input.yul`. Příklad by měl +být uložen v souboru input.yul. ``` { @@ -251,7 +270,7 @@ Následující jednoduchý příklad implementuje funkci mocniny. Lze jej zkompi } ``` -Pokud již máte se smart kontrakty bohaté zkušenosti, plnou implementaci ERC20 v Yul můžete najít [zde](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example). +Pokud již máte se smart kontrakty bohaté zkušenosti, úplnou implementaci ERC20 v jazyce Yul naleznete [zde](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example). ## Fe {#fe} @@ -263,12 +282,12 @@ Pokud již máte se smart kontrakty bohaté zkušenosti, plnou implementaci ERC2 ### Důležité odkazy {#important-links-3} - [GitHub](https://github.com/ethereum/fe) -- [Oznámení Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) -- [Plán vylepšení Fe pro rok 2021](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) -- [Chat na Discordu Fe](https://discord.com/invite/ywpkAXFjZH) -- [Twitter Fe](https://twitter.com/official_fe) +- [Oznámení o Fe](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Plán vývoje Fe na rok 2021](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Chat o Fe na Discordu](https://discord.com/invite/ywpkAXFjZH) +- [Fe na Twitteru](https://twitter.com/official_fe) -### Ukázkový kontrakt {#example-contract-3} +### Příklad kontraktu {#example-contract-3} Následuje jednoduchý kontrakt implementovaný v jazyce Fe. @@ -299,7 +318,7 @@ Uvádíme několik věcí, které byste měli zvážit, pokud jste ještě žád ### Co je skvělé na Solidity? {#solidity-advantages} -- Pokud jste začátečník, najdete mnoho tutoriálů a vzdělávacích nástrojů. Více se dozvíte v sekci [Learn by Coding](/developers/learning-tools/). +- Pokud jste začátečník, najdete mnoho tutoriálů a vzdělávacích nástrojů. Více se o tom dozvíte v sekci [Učte se kódováním](/developers/learning-tools/). - K dispozici je dobrá sada nástrojů pro vývojáře. - Solidity má velkou vývojářskou komunitu, což znamená, že na případné otázky pravděpodobně najdete odpovědi poměrně rychle. @@ -314,11 +333,11 @@ Uvádíme několik věcí, které byste měli zvážit, pokud jste ještě žád - Jednoduchý a funkční nízkoúrovňový jazyk. - Umožňuje dostat se mnohem blíže k surovému EVM, což vám může pomoci s optimalizací spotřeby paliva vašich kontraktů. -## Porovnání jazyků {#language-comparisons} +## Srovnání jazyků {#language-comparisons} -Pro srovnání základní syntaxe, životního cyklu kontraktů, rozhraní, operátorů, datových struktur, funkcí, řídicích struktur a dalších rozdílů se podívejte na tento [cheatsheet od Auditless](https://reference.auditless.com/cheatsheet/) +Pro srovnání základní syntaxe, životního cyklu kontraktů, rozhraní, operátorů, datových struktur, funkcí, řízení toku a dalšího se podívejte na tento [tahák od Auditless](https://reference.auditless.com/cheatsheet/) ## Další čtení {#further-reading} -- [Knihovna Solidity kontraktů od OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/) -- [Solidity by Example](https://solidity-by-example.org) +- [Knihovna kontraktů v Solidity od OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/) +- [Příklady v Solidity](https://solidity-by-example.org) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/libraries/index.md b/public/content/translations/cs/developers/docs/smart-contracts/libraries/index.md index 4cb965d2b29..e51d2c9e135 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/libraries/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/libraries/index.md @@ -1,6 +1,6 @@ --- -title: Knihovny smart kontraktů -description: +title: "Knihovny smart kontraktů" +description: "Objevte znovupoužitelné knihovny chytrých kontraktů a stavební bloky, které urychlí vaše vývojové projekty na Ethereu." lang: cs --- @@ -8,19 +8,19 @@ Ve svém projektu nemusíte psát každý smart kontrakt od nuly. Existuje mnoho ## Předpoklady {#prerequisites} -Než se ponoříte do knihoven smart kontraktů, je dobré mít pevné základy ve struktuře smart kontraktů. Pokud je nemáte, nastudujte si nejdříve [anatomii smart kontraktu](/developers/docs/smart-contracts/anatomy/). +Než se ponoříte do knihoven smart kontraktů, je dobré mít pevné základy ve struktuře smart kontraktů. Pokud jste tak ještě neučinili, přejděte na [anatomii chytrých kontraktů](/developers/docs/smart-contracts/anatomy/). -## Jaký je obsah knihovny {#whats-in-a-library} +## Co je obsahem knihovny {#whats-in-a-library} V knihovnách smart kontraktů obvykle najdete dva druhy stavebních bloků: znovupoužitelné akce, které můžete přidat ke svým kontraktům, a implementace různých standardů. -### Akce {#behaviors} +### Chování {#behaviors} -Při psaní smart kontraktů je pravděpodobné, že se ocitnete v situaci, kdy budete psát podobné vzory znovu a znovu, jako například přiřazení adresy _administrátora_ k provádění zabezpečených operací v kontraktu nebo přidání tlačítka pro nouzové _zastavení_ v případě neočekávaného problému. +Při psaní chytrých kontraktů se vám může stát, že budete opakovaně psát podobné vzory, jako je přiřazení _admin_ adresy pro provádění chráněných operací v kontraktu nebo přidání tlačítka pro nouzové _pozastavení_ v případě neočekávaného problému. -Knihovny smart kontraktů obvykle poskytují znovupoužitelné implementace těchto chování prostřednictvím [knihoven](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) nebo prostřednictvím [dědičnosti](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) v Solidity. +Knihovny chytrých kontraktů obvykle poskytují znovupoužitelné implementace tohoto chování jako [knihovny](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) nebo prostřednictvím [dědičnosti](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) v Solidity. -Jako příklad následuje zjednodušená verze [kontraktu `Ownable`](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) z knihovny [OpenZeppelin Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts), která přiřazuje adresu jako vlastníka kontraktu a poskytuje modifikátor pro umožnění přístupu k metodám pouze tomuto vlastníkovi. +Jako příklad následuje zjednodušená verze [`Ownable` kontraktu](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) z [knihovny OpenZeppelin Contracts](https://github.com/OpenZeppelin/openzeppelin-contracts), která určí adresu jako vlastníka kontraktu a poskytne modifikátor pro omezení přístupu k metodě pouze tomuto vlastníkovi. ```solidity contract Ownable { @@ -37,13 +37,13 @@ contract Ownable { } ``` -Abyste mohli ve svém smart kontraktu použít takovýto stavební blok, musíte jej nejprve importovat a následně jej ve svých vlastních kontraktech rozšířit (dědit z něj). To vám umožní použít modifikátor k zabezpečení vlastních funkcí poskytovaný základním kontraktem `Ownable`. +Abyste mohli ve svém smart kontraktu použít takovýto stavební blok, musíte jej nejprve importovat a následně jej ve svých vlastních kontraktech rozšířit (dědit z něj). To vám umožní použít modifikátor poskytnutý základním kontraktem `Ownable` k zabezpečení vašich vlastních funkcí. ```solidity -import ".../Ownable.sol"; // Path to the imported library +import ".../Ownable.sol"; // Cesta k importované knihovně contract MyContract is Ownable { - // The following function can only be called by the owner + // Následující funkci může volat pouze vlastník function secured() onlyOwner public { msg.sender.transfer(1 ether); } @@ -54,18 +54,18 @@ Dalším populárním příkladem je [SafeMath](https://docs.openzeppelin.com/co ### Standardy {#standards} -Pro usnadnění [kompozice a interoperability](/developers/docs/smart-contracts/composability/) definovala komunita Etherea několik standardů ve formě **ERC (Ethereum Request for Comments)**. Více si o nich můžete přečíst v sekci věnované [standardům](/developers/docs/standards/). +Aby se usnadnila [skladatelnost a interoperabilita](/developers/docs/smart-contracts/composability/), komunita Etherea definovala několik standardů ve formě **ERC**. Více si o nich můžete přečíst v sekci [standardy](/developers/docs/standards/). -Pokud zahrnete ERC do svých smart kontraktů, je dobré hledat standardní implementace místo toho, abyste se snažili vytvořit vlastní. Spousta knihoven smart kontraktů zahrnuje implementace pro nejpopulárnější ERC. Například všudypřítomný [standard ERC20 pro zaměnitelné tokeny](/developers/tutorials/understand-the-erc-20-token-smart-contract/) lze najít v knihovnách [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) a [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20). Navíc některé ERC poskytují kanonické implementace jako součást samotného standardu. +Pokud zahrnete ERC do svých smart kontraktů, je dobré hledat standardní implementace místo toho, abyste se snažili vytvořit vlastní. Spousta knihoven smart kontraktů zahrnuje implementace pro nejpopulárnější ERC. Například všudypřítomný [standard zaměnitelných tokenů ERC20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) lze nalézt v [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token) a [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20). Navíc některé ERC poskytují kanonické implementace jako součást samotného standardu. -Stojí za zmínku, že některé ERC nejsou samostatné, ale jsou rozšířením jiných ERC. Například [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) přidává rozšíření k ERC20 za účelem zlepšení jeho použitelnosti. +Stojí za zmínku, že některé ERC nejsou samostatné, ale jsou rozšířením jiných ERC. Například [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) přidává rozšíření k ERC20 pro zlepšení jeho použitelnosti. ## Jak přidat knihovnu {#how-to} -Vždy se řiďte dokumentací knihovny, kterou přidáváte, kde najdete konkrétní instrukce, jak ji zahrnout do svého projektu. Řada knihoven pro smart kontrakty v Solidity je zabalena pomocí `npm`, takže je můžete jednoduše nainstalovat pomocí příkazu `npm install`. Většina nástrojů pro [kompilaci](/developers/docs/smart-contracts/compiling/) kontraktů prohledá vaši složku `node_modules`, aby našla knihovny smart kontraktů, takže můžete postupovat následovně: +Vždy se řiďte dokumentací knihovny, kterou přidáváte, kde najdete konkrétní instrukce, jak ji zahrnout do svého projektu. Řada knihoven pro chytré kontrakty v Solidity je zabalena pomocí `npm`, takže je můžete jednoduše nainstalovat pomocí příkazu `npm install`. Většina nástrojů pro [kompilaci](/developers/docs/smart-contracts/compiling/) kontraktů prohledá vaši složku `node_modules`, aby našla knihovny chytrých kontraktů, takže můžete postupovat následovně: ```solidity -// This will load the @openzeppelin/contracts library from your node_modules +// Tímto se načte knihovna @openzeppelin/contracts z vaší složky node_modules import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; contract MyNFT is ERC721 { @@ -73,13 +73,13 @@ contract MyNFT is ERC721 { } ``` -Bez ohledu na to, jakou metodu používáte, při zahrnutí knihovny vždy věnujte pozornost verzi [jazyka](/developers/docs/smart-contracts/languages/). Například nemůžete použít knihovnu pro Solidity 0.6, pokud píšete své smart kontrakty v Solidity 0.5. +Bez ohledu na to, jakou metodu používáte, při zahrnutí knihovny vždy sledujte verzi [jazyka](/developers/docs/smart-contracts/languages/). Například nemůžete použít knihovnu pro Solidity 0.6, pokud píšete své smart kontrakty v Solidity 0.5. -## Kdy používat knihovny {#when-to-use} +## Kdy použít {#when-to-use} Použití knihovny smart kontraktů přináší vašemu projektu několik výhod. Především vám ušetří čas tím, že poskytne hotové stavební bloky, které můžete zahrnout do svého systému, místo abyste je museli programovat sami. -Bezpečnost je také velkým přínosem. Open source knihovny smart kontraktů jsou často podrobeny přísné kontrole. Vzhledem k tomu, že na nich závisí mnoho projektů, je komunita silně motivována je neustále kontrolovat. Mnohem častěji lze najít chyby v aplikačním kódu než v knihovnách pro znovupoužitelné smart kontrakty. Některé knihovny také za účelem zajištění vyšší bezpečnosti procházejí [externími audity](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits). +Bezpečnost je také velkým přínosem. Open source knihovny smart kontraktů jsou často podrobeny přísné kontrole. Vzhledem k tomu, že na nich závisí mnoho projektů, je komunita silně motivována je neustále kontrolovat. Mnohem častěji lze najít chyby v aplikačním kódu než v knihovnách pro znovupoužitelné smart kontrakty. Některé knihovny také procházejí [externími audity](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) pro zvýšení bezpečnosti. Nicméně používání knihoven smart kontraktů nese riziko, že do vašeho projektu zahrnete kód, se kterým nejste obeznámeni. Je lákavé importovat kontrakt a přímo jej zahrnout do vašeho projektu, ale bez perfektního porozumění tomu, co tento kontrakt dělá, můžete neúmyslně do systému zavést neočekávané chování a tím si zadělat na problémy. Vždy si předtím, než kód zahrnete do svého projektu, přečtěte jeho dokumentaci a poté si kód sami prohlédněte! @@ -87,31 +87,31 @@ Nakonec při rozhodování, zda zahrnout knihovnu, zvažte její celkové použi ## Související nástroje {#related-tools} -**OpenZeppelin Contracts –** **_nejoblíbenější knihovna pro vývoj bezpečných smart kontraktů._** +**OpenZeppelin Contracts -** **_Nejoblíbenější knihovna pro bezpečný vývoj chytrých kontraktů._** - [Dokumentace](https://docs.openzeppelin.com/contracts/) - [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) - [Komunitní fórum](https://forum.openzeppelin.com/c/general/16) -**DappSys –** **_bezpečné, jednoduché a flexibilní návrhové vzory pro smart kontrakty._** +**DappSys -** **_Bezpečné, jednoduché a flexibilní stavební bloky pro chytré kontrakty._** - [Dokumentace](https://dappsys.readthedocs.io/) - [GitHub](https://github.com/dapphub/dappsys) -**HQ20 –** **_Solidity projekt s kontrakty, knihovnami a příklady, které vám pomohou vytvořit plně funkční distribuované aplikace pro reálný svět._** +**HQ20 -** **_Projekt v Solidity s kontrakty, knihovnami a příklady, které vám pomohou vytvořit plně funkční distribuované aplikace pro reálný svět._** - [GitHub](https://github.com/HQ20/contracts) -**thirdweb Solidity SDK –** **_poskytuje nástroje potřebné pro efektivní vytváření vlastních smart kontraktů._** +**thirdweb Solidity SDK -** **_Poskytuje nástroje potřebné pro efektivní vytváření vlastních chytrých kontraktů_** - [Dokumentace](https://portal.thirdweb.com/contracts/build/overview) - [GitHub](https://github.com/thirdweb-dev/contracts) ## Související návody {#related-tutorials} -- [Security considerations for Ethereum developers](/developers/docs/smart-contracts/security/) _– tutorial o bezpečnostních aspektech při vytváření smart kontraktů, včetně použití knihoven._ -- [Understand the ERC-20 token smart contract](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– tutorial o ERC20 standardu, poskytovaný několika knihovnami._ +- [Bezpečnostní aspekty pro vývojáře na Ethereu](/developers/docs/smart-contracts/security/) _– Tutoriál o bezpečnostních aspektech při vytváření chytrých kontraktů, včetně použití knihoven._ +- [Pochopení chytrého kontraktu tokenu ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Tutoriál o standardu ERC20, poskytovaný několika knihovnami._ -## Další informace {#further-reading} +## 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!_ diff --git a/public/content/translations/cs/developers/docs/smart-contracts/naming/index.md b/public/content/translations/cs/developers/docs/smart-contracts/naming/index.md new file mode 100644 index 00000000000..df78ca7fc2a --- /dev/null +++ b/public/content/translations/cs/developers/docs/smart-contracts/naming/index.md @@ -0,0 +1,101 @@ +--- +title: "Pojmenování chytrých kontraktů" +description: "Osvědčené postupy pro pojmenování chytrých kontraktů Ethereum pomocí ENS" +lang: cs +--- + +Chytré kontrakty jsou základním kamenem decentralizované infrastruktury Etherea, umožňující autonomní aplikace a protokoly. Ale i když se schopnosti kontraktů vyvíjejí, uživatelé a vývojáři se stále spoléhají na nezpracované hexadecimální adresy, aby tyto kontrakty identifikovali a odkazovali na ně. + +Pojmenování chytrých kontraktů pomocí [Služby Ethereum Name Service (ENS)](https://ens.domains/) zlepšuje uživatelskou zkušenost tím, že odstraňuje hexadecimální adresy kontraktů a snižuje riziko útoků, jako je otrava adresy (address poisoning) a podvržení (spoofing). Tato příručka vysvětluje, proč je pojmenování chytrých kontraktů důležité, jak jej lze implementovat a jaké nástroje jsou k dispozici, jako například [Enscribe](https://www.enscribe.xyz), pro zjednodušení procesu a pomoc vývojářům při osvojení si této praxe. + +## Proč pojmenovávat chytré kontrakty? {#why-name-contracts} + +### Člověkem čitelné identifikátory {#human-readable-identifiers} + +Namísto interakce s nečitelnými adresami kontraktů, jako je `0x8f8e...f9e3`, mohou vývojáři a uživatelé používat lidsky čitelná jména jako `v2.myapp.eth`. To zjednodušuje interakce s chytrými kontrakty. + +Umožňuje to [Služba Ethereum Name Service](https://ens.domains/), která poskytuje decentralizovanou službu pro pojmenování ethereových adres. Je to analogické tomu, jak Služba doménových jmen (DNS) umožňuje uživatelům internetu přistupovat k síťovým adresám pomocí jména, jako je ethereum.org, namísto prostřednictvím IP adresy, jako je `104.18.176.152`. + +### Zvýšená bezpečnost a důvěra {#improved-security-and-trust} + +Pojmenované kontrakty pomáhají omezit neúmyslné transakce na nesprávnou adresu. Také pomáhají uživatelům identifikovat kontrakty spojené s konkrétními aplikacemi nebo značkami. To přidává vrstvu reputační důvěry, zejména když jsou jména připojena k dobře známým nadřazeným doménám, jako je `uniswap.eth`. + +Kvůli 42znakové délce ethereové adresy je pro uživatele velmi těžké identifikovat malé změny v adresách, kde bylo upraveno několik znaků. Například adresa jako `0x58068646C148E313CB414E85d2Fe89dDc3426870` by normálně byla zkrácena na `0x580...870` v uživatelských aplikacích, jako jsou peněženky. Uživatel si pravděpodobně nevšimne škodlivé adresy, kde bylo změněno několik znaků. + +Tento typ techniky se používá při útocích podvržením (spoofing) a otravou adres (address poisoning), kdy jsou uživatelé vedeni k domněnce, že komunikují se správnou adresou nebo na ni posílají finanční prostředky, přičemž ve skutečnosti adresa správnou adresu pouze připomíná, ale není stejná. + +Jména ENS pro peněženky a kontrakty chrání proti těmto typům útoků. Podobně jako u útoků podvržením DNS (DNS spoofing) se mohou objevit i útoky podvržením ENS (ENS spoofing), nicméně uživatel si pravděpodobněji všimne překlepu ve jméně ENS než malé úpravy v hexadecimální adrese. + +### Lepší UX pro peněženky a průzkumníky {#better-ux} + +Pokud byl chytrý kontrakt nakonfigurován s názvem ENS, je možné, aby aplikace jako peněženky a průzkumníci blockchainu zobrazovaly názvy ENS pro chytré kontrakty, namísto hexadecimálních adres. To přináší uživatelům výrazné zlepšení uživatelské zkušenosti (UX). + +Například při interakci s aplikací, jako je Uniswap, uživatelé obvykle uvidí, že aplikace, se kterou pracují, je hostována na webové stránce `uniswap.org`, ale pokud Uniswap nepojmenoval své chytré kontrakty pomocí ENS, zobrazí se jim hexadecimální adresa kontraktu. Pokud je kontrakt pojmenován, mohli by místo toho vidět `v4.contracts.uniswap.eth`, což je mnohem užitečnější. + +## Pojmenování při nasazení vs. po nasazení {#when-to-name} + +Existují dva body, ve kterých lze pojmenovat chytré kontrakty: + +- **V době nasazení**: přiřazení jména ENS kontraktu při jeho nasazování. +- **Po nasazení**: namapování stávající adresy kontraktu na nové jméno ENS. + +Oba přístupy se spoléhají na to, že máte vlastnický nebo manažerský přístup k doméně ENS, abyste mohli vytvářet a nastavovat záznamy ENS. + +## Jak funguje pojmenování kontraktů pomocí ENS {#how-ens-naming-works} + +Jména ENS jsou uložena na blockchainu a převádějí se na ethereové adresy prostřednictvím resolverů ENS. Jak pojmenovat chytrý kontrakt: + +1. Zaregistrujte nebo ovládejte nadřazenou doménu ENS (např. `myapp.eth`) +2. Vytvořte subdoménu (např. `v1.myapp.eth`) +3. Nastavte záznam `address` subdomény na adresu kontraktu +4. Nastavte reverzní záznam kontraktu na ENS, aby bylo možné jméno nalézt pomocí jeho adresy + +Jména ENS jsou hierarchická a podporují neomezený počet podjmen. Nastavení těchto záznamů obvykle zahrnuje interakci s registrem ENS a veřejnými resolver kontrakty. + +## Nástroje pro pojmenování kontraktů {#tools} + +Existují dva přístupy k pojmenování chytrých kontraktů. Buď pomocí [aplikace ENS](https://app.ens.domains) s několika manuálními kroky, nebo pomocí [Enscribe](https://www.enscribe.xyz). Ty jsou popsány níže. + +### Ruční nastavení ENS {#manual-ens-setup} + +Pomocí [aplikace ENS](https://app.ens.domains/) mohou vývojáři ručně vytvářet podjména a nastavovat dopředné záznamy adres. Nemohou však nastavit primární název pro chytrý kontrakt nastavením reverzního záznamu pro název prostřednictvím aplikace ENS. Je třeba provést manuální kroky, které jsou popsány v [dokumentaci ENS](https://docs.ens.domains/web/naming-contracts/). + +### Enscribe {#enscribe} + +[Enscribe](https://www.enscribe.xyz) zjednodušuje pojmenování chytrých kontraktů pomocí ENS a zvyšuje důvěru uživatelů v chytré kontrakty. Poskytuje: + +- **Atomické nasazení a pojmenování**: Přiřaďte jméno ENS při nasazování nového kontraktu +- **Pojmenování po nasazení**: Připojte jména k již nasazeným kontraktům +- **Podpora více řetězců**: Funguje napříč sítěmi Ethereum a L2, kde je podporována služba ENS. +- **Údaje o ověření kontraktu**: Zahrnuje údaje o ověření kontraktu získané z více zdrojů pro zvýšení důvěry uživatelů + +Enscribe podporuje jména ENS poskytnutá uživateli, nebo vlastní domény, pokud uživatel nemá jméno ENS. + +Můžete přistoupit k [aplikaci Enscribe](https://app.enscribe.xyz) a začít pojmenovávat a prohlížet chytré kontrakty. + +## Osvědčené postupy {#best-practices} + +- **Používejte jasná, verzovaná jména** jako `v1.myapp.eth`, aby byly aktualizace kontraktů transparentní +- **Nastavte reverzní záznamy** pro propojení kontraktů s názvy ENS pro viditelnost v aplikacích, jako jsou peněženky a průzkumníci blockchainu. +- **Pečlivě sledujte data expirace**, pokud chcete zabránit nechtěným změnám vlastnictví +- **Ověřte zdrojový kód kontraktu**, aby uživatelé mohli věřit, že se pojmenovaný kontrakt chová podle očekávání + +## Rizika {#risks} + +Pojmenování chytrých kontraktů přináší uživatelům Etherea značné výhody, nicméně vlastníci domén ENS musí být při jejich správě ostražití. Mezi významná rizika patří: + +- **Expirace**: Stejně jako názvy DNS mají i registrace názvů ENS konečnou platnost. Je proto životně důležité, aby majitelé sledovali data expirace svých domén a obnovovali je v dostatečném předstihu před jejich vypršením. Jak aplikace ENS, tak Enscribe poskytují majitelům domén vizuální indikátory, když se blíží datum expirace. +- **Změna vlastnictví**: Záznamy ENS jsou na Ethereu reprezentovány jako NFT, kde vlastník konkrétní domény `.eth` drží přidružené NFT. Pokud by tedy vlastnictví tohoto NFT převzal jiný účet, nový vlastník může libovolně upravovat jakékoli záznamy ENS. + +Pro zmírnění těchto rizik by měl být vlastnický účet pro domény 2. úrovně `.eth` (2LD) zabezpečen pomocí peněženky s více podpisy, přičemž pro správu pojmenování kontraktů by měly být vytvořeny subdomény. Tímto způsobem, v případě jakýchkoli náhodných nebo škodlivých změn ve vlastnictví na úrovni subdomény, je může vlastník 2LD přepsat. + +## Budoucnost pojmenovávání kontraktů {#future} + +Pojmenovávání kontraktů se stává osvědčeným postupem pro vývoj dapp, podobně jako doménová jména nahradila IP adresy na webu. S tím, jak více infrastruktury, jako jsou peněženky, průzkumníci a dashboardy, integruje řešení ENS pro kontrakty, pojmenované kontrakty zlepší bezpečnost a sníží počet chyb v celém ekosystému. + +Tím, že pojmenování usnadňuje rozpoznávání a chápání chytrých kontraktů, pomáhá překlenout propast mezi uživateli a aplikacemi na Ethereu a zlepšuje bezpečnost i UX pro uživatele. + +## Další čtení {#further-reading} + +- [Pojmenování chytrých kontraktů pomocí ENS](https://docs.ens.domains/web/naming-contracts/) +- [Pojmenování chytrých kontraktů pomocí Enscribe](https://www.enscribe.xyz/docs). diff --git a/public/content/translations/cs/developers/docs/smart-contracts/security/index.md b/public/content/translations/cs/developers/docs/smart-contracts/security/index.md index 52c958cda97..4879ad9fdde 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/security/index.md @@ -1,54 +1,54 @@ --- -title: Bezpečnost chytrých smluv -description: Přehled pokynů pro vytváření bezpečných smart kontraktů na Ethereu +title: "Bezpečnost chytrých kontraktů" +description: "Přehled pokynů pro vytváření bezpečných smart kontraktů na Ethereu" lang: cs --- Smart kontrakty jsou velmi flexibilní a schopné ovládat velké množství hodnot a dat, přičemž běží nezměnitelnou logikou založenou na kódu spuštěném na blockchainu. To vytvořilo živý ekosystém decentralizovaných aplikací bez nutnosti důvěry, které mají oproti tradičním systémům spoustu výhod. Zároveň však představují příležitosti pro útočníky, kteří se snaží vydělat zneužitím zranitelností ve smart kontraktech. -Veřejné blockchainy, jako je Ethereum, dále komplikují otázku zabezpečení smart kontraktů. Nasazený kód kontraktu _obvykle_ není možné změnit, aby se opravily bezpečnostní chyby, a majetek odcizený ze smart kontraktů je kvůli nezměnitelnosti extrémně obtížné sledovat a prakticky nemožné získat zpět. +Veřejné blockchainy, jako je Ethereum, dále komplikují otázku zabezpečení smart kontraktů. Nasazený kód kontraktu _obvykle_ není možné změnit, aby se opravily bezpečnostní chyby, a majetek odcizený z chytrých kontraktů je kvůli nezměnitelnosti extrémně obtížné sledovat a prakticky nemožné získat zpět. -I když se údaje liší, odhaduje se, že celková hodnota odcizených nebo ztracených prostředků z důvodu bezpečnostních chyb ve smart kontraktech dnes přesahuje 1 miliardu dolarů. To zahrnuje incidenty s vysokým profilem, jako je [hack DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (ukradeno 3,6 milionu ETH, což v dnešní ceně představuje více než 1 miliardu dolarů), [hack multi-sig peněženky Parity](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (škoda ve výši 30 milionů dolarů kvůli hackerům) a [problém se zmrazením peněženek Parity](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (přes 300 milionů dolarů v ETH zůstalo zamčeno navždy). +I když se údaje liší, odhaduje se, že celková hodnota odcizených nebo ztracených prostředků z důvodu bezpečnostních chyb ve smart kontraktech dnes přesahuje 1 miliardu dolarů. To zahrnuje vysoce sledované incidenty, jako je [hack DAO](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (ukradeno 3,6 milionu ETH v hodnotě přes 1 miliardu dolarů v dnešních cenách), [hack peněženky Parity s vícenásobným podpisem](https://www.coindesk.com/markets/2017/07/19/30-million-ether-reported-stolen-due-to-parity-wallet-breach) (ztráta 30 milionů dolarů pro hackery) a [problém se zmrazenou peněženkou Parity](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (více než 300 milionů dolarů v ETH navždy uzamčeno). Výše zmíněné problémy ukazují na důležitost zajištění bezpečnosti smart kontraktů a dělají z ní nezbytnost, do které by měli vývojáři investovat úsilí. Zabezpečení smart kontraktů je vážnou záležitostí, kterou by se měl každý vývojář naučit. Tento průvodce pokrývá bezpečnostní aspekty pro vývojáře Etherea a poskytuje zdroje pro zvýšení bezpečnosti smart kontraktů. ## Předpoklady {#prerequisites} -Než se pustíte do studia bezpečnosti, ujistěte se, že jste obeznámeni se [základy vývoje smart kontraktů](/developers/docs/smart-contracts/). +Než se pustíte do bezpečnosti, ujistěte se, že znáte [základy vývoje chytrých kontraktů](/developers/docs/smart-contracts/). -## Pokyny pro vytváření bezpečných smart kontraktů na Ethereu {#smart-contract-security-guidelines} +## Pokyny pro vytváření bezpečných chytrých kontraktů na Ethereu {#smart-contract-security-guidelines} -### 1. Navrhněte správná omezení přístupu {#design-proper-access-controls} +### 1. Navrhněte správné řízení přístupu {#design-proper-access-controls} -Ve smart kontraktech mohou funkce označené jako `public` nebo `external` volat jakýkoli externí (EOA) nebo kontraktový účet. Specifikace veřejné viditelnosti funkcí je nezbytná, pokud chcete, aby mohli s vaším kontraktem interagovat i ostatní. Funkce označené jako `private` mohou být volány pouze funkcemi v rámci smart kontraktu a nikoliv externími účty. Pokud umožníte každému účastníkovi sítě přístup ke všem funkcím kontraktu, můžete tím způsobit problémy, zejména pokud to znamená, že kdokoliv může provádět citlivé operace (např. vydávání nových tokenů). +V chytrých kontraktech mohou funkce označené jako `public` nebo `external` volat jakýkoli externě vlastněný účet (EOA) nebo účet kontraktu. Specifikace veřejné viditelnosti funkcí je nezbytná, pokud chcete, aby mohli s vaším kontraktem interagovat i ostatní. Funkce označené jako `private` však mohou být volány pouze funkcemi v rámci chytrého kontraktu a nikoli externími účty. Pokud umožníte každému účastníkovi sítě přístup ke všem funkcím kontraktu, můžete tím způsobit problémy, zejména pokud to znamená, že kdokoliv může provádět citlivé operace (např. vydávání nových tokenů). -Aby se zabránilo neoprávněnému použití funkcí smart kontraktu, je nutné implementovat bezpečné přístupové kontroly. Mechanismy přístupové kontroly omezují schopnost používat určité funkce ve smart kontraktu na schválené subjekty, jako jsou účty odpovědné za správu kontraktu. **Vzor Ownable** a **kontrola přístupu založená na rolích** jsou dva vzory užitečné pro implementaci přístupové kontroly ve smart kontraktech: +Aby se zabránilo neoprávněnému použití funkcí smart kontraktu, je nutné implementovat bezpečné přístupové kontroly. Mechanismy přístupové kontroly omezují schopnost používat určité funkce ve smart kontraktu na schválené subjekty, jako jsou účty odpovědné za správu kontraktu. Vzor **Ownable** a **řízení přístupu na základě rolí** jsou dva užitečné vzory pro implementaci řízení přístupu v chytrých kontraktech: #### Vzor Ownable {#ownable-pattern} Tento vzor přiřadí při vytváření kontraktu adresu jako „vlastníka“ kontraktu. Chráněným funkcím je přiřazen modifikátor `OnlyOwner`, který zajistí, že kontrakt ověří identitu volající adresy před spuštěním funkce. Volání chráněných funkcí z jiných adres, než je adresa vlastníka kontraktu, se vždy vrátí zpět, čímž se zabrání přístupu nežádoucích adres. -#### Kontrola přístupu založená na rolích {#role-based-access-control} +#### Řízení přístupu na základě rolí {#role-based-access-control} -Registrace jediné adresy jako `vlastníka` smart kontraktu představuje riziko centralizace a jediného bodu selhání. Pokud jsou kompromitovány klíče účtu vlastníka, útočníci mohou napadnout i kontrakt, který vlastní. Proto může být lepší možností použít kontrolu přístupu založenou na rolích s účty několika správců. +Registrace jediné adresy jako `Owner` v chytrém kontraktu představuje riziko centralizace a jediný bod selhání. Pokud jsou kompromitovány klíče účtu vlastníka, útočníci mohou napadnout i kontrakt, který vlastní. Proto může být lepší možností použít kontrolu přístupu založenou na rolích s účty několika správců. V řízení přístupu na základě rolí je přístup k citlivým funkcím rozdělen mezi několik důvěryhodných adres. Jeden účet může být například zodpovědný za vydávání nových tokenů, zatímco jiný účet provádí vylepšení nebo kontrakt pozastavuje. Decentralizace řízení přístupu tímto způsobem eliminuje jednotlivé body selhání a snižuje nutnost uživatele vašemu kontraktu slepě důvěřovat. ##### Použití multi-signature peněženek -Dalším přístupem k implementaci bezpečné přístupové kontroly je možnost ke správě kontraktu použít [multi-signature účet](/developers/docs/smart-contracts/#multisig). Na rozdíl od běžného EOA jsou multi-signature účty vlastněny několika subjekty a k provedení transakcí vyžadují podpisy od předem daného minimálního počtu účtů – například alespoň 3 z 5. +Dalším přístupem k implementaci bezpečného řízení přístupu je použití [účtu s vícenásobným podpisem](/developers/docs/smart-contracts/#multisig) ke správě kontraktu. Na rozdíl od běžného EOA jsou multi-signature účty vlastněny několika subjekty a k provedení transakcí vyžadují podpisy od předem daného minimálního počtu účtů – například alespoň 3 z 5. Použití multisigu pro řízení přístupu přináší další vrstvu zabezpečení, protože akce na smart kontraktu vyžadují souhlas více stran. To je užitečné zejména v případě, že je použití vzoru Ownable nezbytné, protože útočníkovi nebo i insiderovi se špatným úmyslem komplikuje manipulaci s citlivými funkcemi kontraktu. -### 2. Použijte příkazy require(), assert() a revert() k ochraně akcí kontraktu {#use-require-assert-revert} +### 2. Použijte příkazy `require()`, `assert()` a `revert()` k ochraně operací kontraktu {#use-require-assert-revert} -Jakmile je váš smart kontrakt nasazen na blockchain, volat jeho veřejné funkce může kdokoliv. Jelikož nemůžete předem vědět, jak budou externí účty s kontraktem interagovat, je ideální volbou implementovat interní zabezpečení proti problematickým operacím ještě před nasazením kontraktu. Pomocí příkazů `require()`, `assert()` a `revert()` můžete nastavit požadované chování smart kontraktu za účelem vyvolání výjimek a vrácení změn stavu, pokud exekuce funkce nebude úspěšná. +Jakmile je váš smart kontrakt nasazen na blockchain, volat jeho veřejné funkce může kdokoliv. Jelikož nemůžete předem vědět, jak budou externí účty s kontraktem interagovat, je ideální volbou implementovat interní zabezpečení proti problematickým operacím ještě před nasazením kontraktu. Správné chování v chytrých kontraktech můžete vynutit pomocí příkazů `require()`, `assert()` a `revert()`, které spouštějí výjimky a vracejí změny stavu, pokud se provádění nepodaří splnit určité požadavky. -**`require()`**: ``Vyžaduje, aby byly předem definované podmínky splněny před spuštěním volané funkce. Příkaz `require` lze použít k ověření uživatelských vstupů, kontrole stavových proměnných nebo ověření identity volajícího účtu před pokračováním exekuce funkce. +**`require()`**: `require` se definuje na začátku funkcí a zajišťuje, že jsou splněny předem definované podmínky před spuštěním volané funkce. Příkaz `require` lze použít k ověření vstupů uživatele, kontrole stavových proměnných nebo ověření identity volajícího účtu před pokračováním ve funkci. -**`assert()`**: `assert()` se používá k detekci interních chyb a kontrole porušení „invariantů“ v kódu. Invariant je logické tvrzení o stavu kontraktu, které by mělo platit pro všechny exekuce funkcí. Příkladem invariantu je maximální celková nabídka nebo zůstatek tokenového kontraktu. Použití funkce `assert()` zajišťuje, že váš kontrakt nikdy nedosáhne zranitelného stavu, a pokud ano, všechny změny stavových proměnných budou vráceny zpět. +**`assert()`**: `assert()` se používá k detekci vnitřních chyb a kontrole porušení „invariantů“ ve vašem kódu. Invariant je logické tvrzení o stavu kontraktu, které by mělo platit pro všechny exekuce funkcí. Příkladem invariantu je maximální celková nabídka nebo zůstatek tokenového kontraktu. Použití `assert()` zajišťuje, že váš kontrakt nikdy nedosáhne zranitelného stavu, a pokud ano, všechny změny stavových proměnných se vrátí zpět. -**`revert()`**: `revert()` může být použit v if-else příkazu k vyvolání výjimky, pokud není splněna požadovaná podmínka. Ukázkový kontrakt níže používá `revert()` k ochraně exekuce funkcí: +**`revert()`**: `revert()` lze použít v příkazu if-else, který spustí výjimku, pokud není splněna požadovaná podmínka. Níže uvedený ukázkový kontrakt používá `revert()` k ochraně provádění funkcí: ``` pragma solidity ^0.8.4; @@ -59,7 +59,7 @@ contract VendingMachine { function buy(uint amount) public payable { if (amount > msg.value / 2 ether) revert("Not enough Ether provided."); - // Perform the purchase. + // Proveďte nákup. } function withdraw() public { if (msg.sender != owner) @@ -70,19 +70,19 @@ contract VendingMachine { } ``` -### 3. Testování smart kontraktů a ověřování správnosti kódu {#test-smart-contracts-and-verify-code-correctness} +### 3. Testujte chytré kontrakty a ověřujte správnost kódu {#test-smart-contracts-and-verify-code-correctness} -Neměnnost kódu běžícího na [Virtuálním stroji Etherea (EVM)](/developers/docs/evm/) znamená, že smart kontrakty vyžadují vyšší úroveň kontroly kvality během vývojové fáze. Důkladné testování vašeho kontraktu a sledování jakýchkoli neočekávaných výsledků výrazně zvýší bezpečnost a dlouhodobě ochrání vaše uživatele. +Neměnnost kódu běžícího v [Ethereum Virtual Machine](/developers/docs/evm/) znamená, že chytré kontrakty vyžadují vyšší úroveň hodnocení kvality během vývojové fáze. Důkladné testování vašeho kontraktu a sledování jakýchkoli neočekávaných výsledků výrazně zvýší bezpečnost a dlouhodobě ochrání vaše uživatele. -Obvyklou metodou je psát malé jednotkové testy (unit tests) pomocí mock dat, která kontrakt očekává od uživatelů. [Jednotkové testování](/developers/docs/smart-contracts/testing/#unit-testing) je dobré pro testování funkčnosti určitých funkcí a zajištění, že smart kontrakt funguje podle očekávání. +Obvyklou metodou je psát malé jednotkové testy (unit tests) pomocí mock dat, která kontrakt očekává od uživatelů. [Jednotkové testování](/developers/docs/smart-contracts/testing/#unit-testing) je dobré pro testování funkčnosti určitých funkcí a zajištění, že chytrý kontrakt funguje podle očekávání. Jednotkové testování je při zajištění bezpečnosti smart kontraktů účinné bohužel jen minimálně, pokud se používá izolovaně. Jednotkový test může prokázat, že funkce správně provádí operace s mock daty, ale obecně jsou jednotkové testy účinné pouze do té míry, jak jsou napsány. To ztěžuje detekci opomenutých hraničních případů a zranitelností, které by mohly ohrozit bezpečnost vašeho smart kontraktu. -Lepším přístupem je kombinovat jednotkové testování s testováním založeným na vlastnostech (property-based testing) prováděným pomocí [statické a dynamické analýzy](/developers/docs/smart-contracts/testing/#static-dynamic-analysis). Statická analýza se spoléhá na nízkoúrovňové reprezentace, jako jsou [grafy toku kontroly (control flow graphs)](https://en.wikipedia.org/wiki/Control-flow_graph) a [abstraktní syntaktické stromy](https://deepsource.io/glossary/ast/) (abstract syntax trees), za účelem analýzy dosažitelných stavů programu a možných exekučních cest. Mezitím dynamické analytické techniky, jako je [fuzzing smart kontraktů](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), provádějí kód kontraktu s náhodnými vstupními hodnotami, aby detekovaly operace, které porušují bezpečnostní vlastnosti. +Lepším přístupem je kombinovat jednotkové testování s testováním založeným na vlastnostech, které se provádí pomocí [statické a dynamické analýzy](/developers/docs/smart-contracts/testing/#static-dynamic-analysis). Statická analýza se spoléhá na nízkoúrovňové reprezentace, jako jsou [grafy toku řízení](https://en.wikipedia.org/wiki/Control-flow_graph) a [abstraktní syntaktické stromy](https://deepsource.io/glossary/ast/) k analýze dosažitelných stavů programu a cest provádění. Mezitím techniky dynamické analýzy, jako je [fuzzing chytrých kontraktů](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), spouštějí kód kontraktu s náhodnými vstupními hodnotami, aby odhalily operace, které porušují bezpečnostní vlastnosti. -[Formální verifikace](/developers/docs/smart-contracts/formal-verification) je dalším postupem pro ověřování bezpečnostních vlastností ve smart kontraktech. Na rozdíl od běžného testování může formální verifikace definitivně prokázat nepřítomnost chyb ve smart kontraktu. Toho lze docílit vytvořením formální specifikace, která zachycuje požadované bezpečnostní vlastnosti, a prokázáním, že formální model kontraktů odpovídá této specifikaci. +[Formální ověření](/developers/docs/smart-contracts/formal-verification) je další technika pro ověřování bezpečnostních vlastností v chytrých kontraktech. Na rozdíl od běžného testování může formální verifikace definitivně prokázat nepřítomnost chyb ve smart kontraktu. Toho lze docílit vytvořením formální specifikace, která zachycuje požadované bezpečnostní vlastnosti, a prokázáním, že formální model kontraktů odpovídá této specifikaci. -### 4. Požádejte o nezávislé přezkoumání vašeho kódu {#get-independent-code-reviews} +### 4. Požádejte o nezávislou revizi svého kódu {#get-independent-code-reviews} Po testování vašeho kontraktu je dobré požádat jiné osoby, aby zkontrolovaly zdrojový kód a odhalily případné bezpečnostní problémy. Testování neodhalí všechny chyby ve smart kontraktu, ale nezávislé přezkoumání zvyšuje možnost odhalení zranitelností. @@ -92,18 +92,18 @@ Zajištění auditu smart kontraktů je jedním ze způsobů, jak provést nezá Je však důležité nenahlížet na audity jako na všelék. Audity smart kontraktů neodhalí každou chybu a jsou navrženy především pro poskytování dalšího kola kontrol, které mohou pomoci odhalit problémy, které vývojáři během počátečního vývoje a testování přehlédli. Doporučuje se dodržovat osvědčené postupy při práci s auditory, jako je řádné dokumentování kódu a přidávání komentářů, aby se přínos takového auditu maximalizoval. -- [Smart contract auditing tips & tricks](https://twitter.com/tinchoabbate/status/1400170232904400897) – _@tinchoabbate_ -- [Make the most out of your audit](https://inference.ag/blog/2023-08-14-tips/) – _Inference_ +- [Tipy a triky pro auditování chytrých kontraktů](https://twitter.com/tinchoabbate/status/1400170232904400897) – _@tinchoabbate_ +- [Využijte svůj audit na maximum](https://inference.ag/blog/2023-08-14-tips/) – _Inference_ -#### Odměna za vyřešení chyby {#bug-bounties} +#### Odměny za nalezení chyb {#bug-bounties} Zřízení programu bug bounty, tedy programu odměn za vyřešení chyb, je dalším přístupem k implementaci externích kontrol kódu. Bug bounty je finanční odměna poskytovaná jednotlivcům (obvykle whitehat hackerům), kteří objeví zranitelnosti v aplikaci. -Při správném použití bug bounty motivuje členy hackerské komunity k inspekci vašeho kódu a odhalení kritických chyb. Příkladem z reálného světa je „infinite money bug“, který by útočníkovi umožnil vytvořit neomezené množství etheru na [Optimismu](https://www.optimism.io/), protokolu [druhé vrstvy](/layer-2/) na Ethereu. Naštěstí whitehat hacker [odhalil tuto chybu](https://www.saurik.com/optimism.html) a informoval tým, čímž si [vysloužil velkou odměnu](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). +Při správném použití bug bounty motivuje členy hackerské komunity k inspekci vašeho kódu a odhalení kritických chyb. Příkladem z reálného života je chyba „nekonečných peněz“, která by útočníkovi umožnila vytvořit neomezené množství etheru na [Optimism](https://www.optimism.io/), protokolu [druhé vrstvy](/layer-2/) běžícím na Ethereu. Naštěstí whitehat hacker [objevil chybu](https://www.saurik.com/optimism.html) a informoval tým, za což [získal velkou odměnu](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). -Užitečnou strategií je nastavit odměnu v programu bug bounty v poměru k výši prostředků, které jsou v sázce. Tento přístup, popisovaný jako „[škálovatelná bug bounty](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)“, finančně motivuje jednotlivce zodpovědně zveřejnit zranitelnosti namísto jejich zneužití. +Užitečnou strategií je nastavit odměnu v programu bug bounty v poměru k výši prostředků, které jsou v sázce. Tento přístup, popisovaný jako „[scaling bug bounty](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)“, poskytuje finanční pobídky pro jednotlivce, aby zodpovědně zveřejňovali zranitelnosti, místo aby je zneužívali. -### 5. Při vývoji smart kontraktů dodržujte osvědčené postupy {#follow-smart-contract-development-best-practices} +### 5. Dodržujte osvědčené postupy při vývoji chytrých kontraktů {#follow-smart-contract-development-best-practices} Existence auditů a bug bounty vás nezbavuje odpovědnosti za psaní kvalitního kódu. Bezpečnost smart kontraktů začíná dodržováním správných návrhových a vývojových procesů: @@ -113,29 +113,29 @@ Existence auditů a bug bounty vás nezbavuje odpovědnosti za psaní kvalitníh - Zajistěte, aby měl každý pull request alespoň jednoho nezávislého recenzenta – pokud pracujete na projektu sami, zvažte, zda nenajít jiné vývojáře a poprosit je o vzájemné recenzování vašich kódů -- Pro testování, kompilaci a nasazování smart kontraktů používejte [vývojové prostředí](/developers/docs/frameworks/) +- Používejte [vývojové prostředí](/developers/docs/frameworks/) pro testování, kompilaci a nasazování chytrých kontraktů -- Spusťte svůj kód pomocí základních nástrojů pro analýzu kódu, jako jsou [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril a Slither. Ideálně byste to měli udělat před každým sloučením pull requestu a porovnat rozdíly ve výstupu +- Prožeňte svůj kód základními nástroji pro analýzu kódu, jako jsou [Cyfrin Aderyn](https://github.com/Cyfrin/aderyn), Mythril a Slither. Ideálně byste to měli udělat před každým sloučením pull requestu a porovnat rozdíly ve výstupu - Ujistěte se, že váš kód se kompiluje bez chyb a kompilátor Solidity nevydává žádná varování -- Správně dokumentujte svůj kód (pomocí [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) a uveďte podrobnosti o architektuře kontraktu ve snadno srozumitelném jazyce. To usnadní audit a přezkoumání vašeho kódu. +- Správně dokumentujte svůj kód (pomocí [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html)) a popisujte podrobnosti o architektuře kontraktu ve snadno srozumitelném jazyce. To usnadní audit a přezkoumání vašeho kódu. -### 6. Implementujte robustní plány obnovy po nehodě {#implement-disaster-recovery-plans} +### 6. Implementujte robustní plány pro zotavení po havárii {#implement-disaster-recovery-plans} Navrhování bezpečných přístupových kontrol, implementace modifikátorů funkcí a další doporučení mohou zlepšit bezpečnost smart kontraktů, ale nemohou vyloučit možnost zlovolných útoků. Budování bezpečných smart kontraktů vyžaduje „přípravu na selhání“ a mít záložní plán pro efektivní reakci na útoky. Správný plán obnovy po nehodě zahrnuje některé nebo všechny z následujících komponent: -#### Aktualizace kontraktů {#contract-upgrades} +#### Upgrady kontraktů {#contract-upgrades} I když jsou smart kontrakty na Ethereu ve výchozím nastavení neměnné, pomocí vzorů aktualizace je možné dosáhnout určité míry změny. Aktualizace kontraktů je nezbytná v případech, kdy kritická chyba činí váš starý kontrakt nepoužitelným a nasazení nové logiky je nejrealističtější možností. Mechanismy aktualizace kontraktů fungují různě, ale jedním z populárních přístupů je „proxy vzor“. [Proxy vzory](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) rozdělují stav a logiku aplikace mezi _dva_ kontrakty. První kontrakt (tzv. „proxy kontrakt“) uchovává stavové proměnné (např. zůstatky uživatelů), zatímco druhý kontrakt (tzv. „logický kontrakt“) obsahuje kód pro vykonávání funkcí kontraktu. -Účty interagují s proxy kontraktem, který přesměruje všechna volání funkcí na logický kontrakt pomocí nízkoúrovňového volání [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries). Na rozdíl od běžného volání zpráv `delegatecall()` zajišťuje, že kód spuštěný na adrese logického kontraktu je prováděn v kontextu volajícího kontraktu. To znamená, že logický kontrakt vždy zapisuje do úložiště proxy kontraktu (místo vlastního úložiště) a původní hodnoty `msg.sender` a `msg.value` jsou zachovány. +Účty interagují s proxy kontraktem, který odesílá všechna volání funkcí do logického kontraktu pomocí nízkoúrovňového volání [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries). Na rozdíl od běžného volání zprávy `delegatecall()` zajišťuje, že kód spuštěný na adrese logického kontraktu je prováděn v kontextu volajícího kontraktu. To znamená, že logický kontrakt bude vždy zapisovat do úložiště proxy (místo do svého vlastního úložiště) a původní hodnoty `msg.sender` a `msg.value` jsou zachovány. Delegování volání na logický kontrakt vyžaduje uložení jeho adresy do úložiště proxy kontraktu. Proto je aktualizace logiky kontraktu pouze otázkou nasazení nového logického kontraktu a uložení nové adresy do proxy kontraktu. Následná volání proxy kontraktu jsou pak automaticky směrována na nový logický kontrakt, čímž dojde k „aktualizaci“ kontraktu bez skutečné modifikace kódu. -[Další informace o aktualizaci kontraktu](/developers/docs/smart-contracts/upgrading/). +[Více o upgradování kontraktů](/developers/docs/smart-contracts/upgrading/). #### Nouzové zastavení {#emergency-stops} @@ -143,16 +143,16 @@ Jak již bylo zmíněno, i přes rozsáhlé audity a testování není možné o Nejradikálnější možností je implementovat funkci „nouzového zastavení“, která zablokuje volání zranitelných funkcí v kontraktu. Nouzové zastavení obvykle zahrnuje následující komponenty: -1. Globální Booleanovská proměnná, která indikuje, zda je smart kontrakt zastaven, či nikoli. Tato proměnná je při spouštění kontraktu nastavena na `false`, ale při zastavení kontraktu se změní na `true`. +1. Globální Booleanovská proměnná, která indikuje, zda je smart kontrakt zastaven, či nikoli. Tato proměnná je při nastavování kontraktu nastavena na `false`, ale po zastavení kontraktu se vrátí na `true`. 2. Funkce, které odkazují na Booleanovskou proměnnou při jejich provádění. Tyto funkce jsou přístupné, když smart kontrakt není pozastaven, a stávají se nepřístupnými, když je funkce nouzového zastavení aktivována. -3. Entita, která má přístup k funkci nouzového zastavení a která nastavuje Booleanovskou proměnnou na `true`. Aby se zabránilo zlovolným akcím, lze volání této funkce omezit na důvěryhodnou adresu (např. vlastníka kontraktu). +3. Entita, která má přístup k funkci nouzového zastavení, která nastavuje booleovskou proměnnou na `true`. Aby se zabránilo zlovolným akcím, lze volání této funkce omezit na důvěryhodnou adresu (např. vlastníka kontraktu). -Jakmile je nouzové zastavení aktivováno, určité funkce nebudou volatelné. Toho lze dosáhnout obalením vybraných funkcí v modifikátoru, který odkazuje na globální proměnnou. Níže je uveden [příklad](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) implementace tohoto vzoru v kontraktech: +Jakmile je nouzové zastavení aktivováno, určité funkce nebudou volatelné. Toho lze dosáhnout obalením vybraných funkcí v modifikátoru, který odkazuje na globální proměnnou. Níže je [příklad](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol), který popisuje implementaci tohoto vzoru v kontraktech: ```solidity -// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk. +// Tento kód nebyl profesionálně auditován a neslibuje žádnou bezpečnost ani správnost. Používejte na vlastní nebezpečí. contract EmergencyStop { @@ -169,7 +169,7 @@ contract EmergencyStop { } modifier onlyAuthorized { - // Check for authorization of msg.sender here + // Zde zkontrolujte autorizaci msg.sender _; } @@ -182,63 +182,63 @@ contract EmergencyStop { } function deposit() public payable stoppedInEmergency { - // Deposit logic happening here + // Zde probíhá logika vkladu } function emergencyWithdraw() public onlyWhenStopped { - // Emergency withdraw happening here + // Zde probíhá nouzový výběr } } ``` Tento příklad ukazuje základní funkce nouzového zastavení: -- Proměnná `isStopped` je Booleanovská hodnota, která se na začátku vyhodnocuje jako `false` a změní se na `true`, když kontrakt vstoupí do nouzového režimu. +- `isStopped` je booleovská hodnota, která se na začátku vyhodnotí jako `false` a jako `true`, když kontrakt vstoupí do nouzového režimu. -- Modifikátory funkcí `onlyWhenStopped` a `stoppedInEmergency` kontrolují proměnnou `isStopped`. Modifikátor `stoppedInEmergency` se používá k ovládání funkcí, které by měly být nepřístupné, když je kontrakt zranitelný (např. funkce `deposit()`). Volání těchto funkcí se jednoduše zruší. +- Modifikátory funkcí `onlyWhenStopped` a `stoppedInEmergency` kontrolují proměnnou `isStopped`. `stoppedInEmergency` se používá k řízení funkcí, které by měly být nepřístupné, když je kontrakt zranitelný (např. `deposit()`). Volání těchto funkcí se jednoduše zruší. -Modifikátor `onlyWhenStopped` se používá pro funkce, které by měly být volatelné během nouze (např. `funkce emergencyWithdraw()`). Tyto funkce mohou pomoci situaci vyřešit, a proto jsou vyloučeny ze seznamu „omezených funkcí“. +`onlyWhenStopped` se používá pro funkce, které by měly být volatelné během nouzového stavu (např. `emergencyWithdraw()`). Tyto funkce mohou pomoci situaci vyřešit, a proto jsou vyloučeny ze seznamu „omezených funkcí“. Použití funkce nouzového zastavení poskytuje efektivní řešení vážných zranitelností smart kontraktu. Nicméně to zvyšuje nutnost uživatelů důvěřovat vývojářům, že tuto funkci neaktivují z vlastních sobeckých důvodů. Za tímto účelem je možné decentralizovat kontrolu nad nouzovým zastavením buď tím, že bude podléhat hlasovacímu mechanismu na blockchainu, časovému zámku nebo schválení z multisig peněženky. #### Monitorování událostí {#event-monitoring} -[Události](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) umožňují sledovat volání funkcí smart kontraktů a monitorovat změny stavových proměnných. Ideální je naprogramovat váš smart kontrakt tak, aby zapsal událost pokaždé, když nějaká strana provede bezpečnostně kritickou akci (např. výběr prostředků). +[Události](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) umožňují sledovat volání funkcí chytrých kontraktů a monitorovat změny stavových proměnných. Ideální je naprogramovat váš smart kontrakt tak, aby zapsal událost pokaždé, když nějaká strana provede bezpečnostně kritickou akci (např. výběr prostředků). Protokolování událostí a jejich monitorování mimo blockchain poskytuje přehled o činnostech kontraktu a pomáhá rychleji odhalit škodlivé akce. To znamená, že váš tým může rychleji reagovat na útoky a podniknout kroky ke zmírnění dopadu na uživatele, jako je pozastavení funkcí nebo provedení aktualizace. Můžete si také vybrat hotový nástroj pro monitorování, který automaticky přeposílá upozornění pokaždé, když někdo interaguje s vašimi kontrakty. Tyto nástroje vám umožní vytvářet vlastní upozornění na základě různých spouštěcích událostí, jako je objem transakcí, četnost volání funkcí nebo specifické funkce zapojené do transakce. Například byste mohli naprogramovat upozornění, které se objeví, když částka vybraná v jedné transakci překročí určitou prahovou hodnotu. -### 7. Návrh bezpečných řídicích systémů {#design-secure-governance-systems} +### 7. Navrhněte bezpečné systémy správy {#design-secure-governance-systems} Možná budete chtít decentralizovat svou aplikaci tím, že předáte kontrolu nad hlavními smart kontrakty členům komunity. V tomto případě bude systém chytrých kontraktů zahrnovat řídicí modul — mechanismus, který členům komunity umožní schvalovat administrativní kroky prostřednictvím systému řízení na blockchainu. Například návrh na aktualizaci proxy kontraktu na novou implementaci může být odhlasován držiteli tokenů. Decentralizované řízení může být prospěšné, zejména proto, že sladí zájmy vývojářů a koncových uživatelů. Nicméně mechanismy správy smart kontraktů mohou při nesprávné implementaci představovat nové riziko. Pravděpodobný scénář je, že útočník získá obrovskou hlasovací sílu (měřenou počtem držených tokenů) tím, že si vezme [bleskovou půjčku](/defi/#flash-loans) a protlačí škodlivý návrh. -Jedním ze způsobů, jak předcházet problémům spojeným s řízením na blockchainu, je [použití časového zámku](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). Časový zámek brání smart kontraktu v provádění předem daných akcí, dokud neuplyne stanovené množství času. Další strategie zahrnují přiřazení „váhy hlasu“ každému tokenu na základě toho, jak dlouho ho adresa držela, nebo měření hlasovací síly adresy v historickém období (například 2–3 bloky v minulosti) namísto aktuálního bloku. Obě metody snižují možnosti rychlého získávání hlasovací síly za účelem ovlivnění hlasování na blockchainu. +Jedním ze způsobů, jak předcházet problémům souvisejícím se správou na blockchainu, je [použití časového zámku](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/). Časový zámek brání smart kontraktu v provádění předem daných akcí, dokud neuplyne stanovené množství času. Další strategie zahrnují přiřazení „váhy hlasu“ každému tokenu na základě toho, jak dlouho ho adresa držela, nebo měření hlasovací síly adresy v historickém období (například 2–3 bloky v minulosti) namísto aktuálního bloku. Obě metody snižují možnosti rychlého získávání hlasovací síly za účelem ovlivnění hlasování na blockchainu. -Více o [návrhu systémů bezpečného řízení](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [různých hlasovacích mechanismech v DAO](https://hackernoon.com/governance-is-the-holy-grail-for-daos) a [běžných vektorech útoku DAO využívajících DeFi](https://dacian.me/dao-governance-defi-attacks) najdete ve sdílených odkazech. +Více o [navrhování bezpečných systémů správy](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), [různých mechanismech hlasování v DAO](https://hackernoon.com/governance-is-the-holy-grail-for-daos) a [běžných vektorech útoků na DAO s využitím DeFi](https://dacian.me/dao-governance-defi-attacks) ve sdílených odkazech. ### 8. Snižte složitost kódu na minimum {#reduce-code-complexity} Vývojáři tradičních softwarů znají princip KISS („Keep It Simple, Stupid“), který doporučuje zbytečně softwarový design nekomplikovat. Tento princip vychází z myšlenky, že „komplexní systémy selhávají složitým způsobem“ a jsou náchylnější k nákladným chybám. -Udržování jednoduchosti je zvláště důležité při psaní smart kontraktů, vzhledem k tomu, že smart kontrakty potenciálně spravují velké objemy aktiv. Tipem pro docílení jednoduchosti při psaní smart kontraktů je opětovné použití stávajících knihoven, jako je [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/), kdekoliv je to možné. Protože tyto knihovny byly důkladně auditovány a testovány vývojáři, jejich použití snižuje pravděpodobnost chyb při psaní nové funkcionality od začátku. +Udržování jednoduchosti je zvláště důležité při psaní smart kontraktů, vzhledem k tomu, že smart kontrakty potenciálně spravují velké objemy aktiv. Tipem pro dosažení jednoduchosti při psaní chytrých kontraktů je, pokud je to možné, opětovné použití existujících knihoven, jako jsou [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/). Protože tyto knihovny byly důkladně auditovány a testovány vývojáři, jejich použití snižuje pravděpodobnost chyb při psaní nové funkcionality od začátku. Dalším běžným doporučením je psát malé funkce a udržovat smart kontrakty modulární rozdělením obchodní logiky mezi více kontraktů. Nejenže psaní jednoduššího kódu snižuje možnosti útoku na váš smart kontrakt, ale také usnadňuje ověřování správnosti celého systému a včasné odhalení možných návrhových chyb. -### 9. Chraňte se před běžnými zranitelnostmi smart kontraktů {#mitigate-common-smart-contract-vulnerabilities} +### 9. Obrana proti běžným zranitelnostem chytrých kontraktů {#mitigate-common-smart-contract-vulnerabilities} -#### Opětovný vstup {#reentrancy} +#### Opětovný vstup (reentrancy) {#reentrancy} -EVM neumožňuje souběžné zpracování (konkurenci), což znamená, že dva kontrakty zapojené do volání zprávy nemohou běžet současně. Externí volání pozastaví exekuci a paměť volajícího kontraktu, dokud se volání nevrátí, načež provádění pokračuje normálně. Tento proces lze formálně popsat jako předání [řízení](https://www.computerhope.com/jargon/c/contflow.htm) dalšímu kontraktu. +EVM neumožňuje souběžné zpracování (konkurenci), což znamená, že dva kontrakty zapojené do volání zprávy nemohou běžet současně. Externí volání pozastaví exekuci a paměť volajícího kontraktu, dokud se volání nevrátí, načež provádění pokračuje normálně. Tento proces lze formálně popsat jako předání [toku řízení](https://www.computerhope.com/jargon/c/contflow.htm) jinému kontraktu. Ačkoli je tento proces většinou neškodný, předání řízení nedůvěryhodným kontraktům může způsobit problémy, jako je reentrancy (opětovný vstup). Útok opětovným vstupem nastane, když škodlivý kontrakt znovu volá do zranitelného kontraktu, než je původní funkce dokončena. Tento typ útoku je nejlepší vysvětlovat na příkladu. Mějme jednoduchý chytrý kontrakt (Victim), který umožňuje komukoli vložit a vybrat ether: ```solidity -// This contract is vulnerable. Do not use in production +// Tento kontrakt je zranitelný. Nepoužívejte v produkčním prostředí contract Victim { mapping (address => uint256) public balances; @@ -256,15 +256,15 @@ contract Victim { } ``` -Tento kontrakt nabízí funkci `withdraw()`, která umožňuje uživatelům vybrat ETH, které do kontraktu vložili v minulosti. Při zpracování výběru kontrakt provádí následující operace: +Tento kontrakt odhaluje funkci `withdraw()`, která uživatelům umožňuje vybrat ETH dříve vložené do kontraktu. Při zpracování výběru kontrakt provádí následující operace: 1. Zjistí zůstatek ETH uživatele 2. Odešle prostředky na volající adresu 3. Resetuje jejich zůstatek na 0, aby zabránil dalším výběrům od uživatele -Funkce `withdraw()` v kontraktu `Victim` následuje vzor „kontroly-interakce-efekty“ (checks-interactions-effects). Nejprve _zkontroluje_, zda jsou splněny podmínky pro exekuci (tzn. uživatel má kladný zůstatek ETH), poté provede _interakci_ odesláním ETH na adresu volajícího a nakonec aplikuje _efekty_ transakce (tj. sníží zůstatek uživatele). +Funkce `withdraw()` v kontraktu `Victim` se řídí vzorem „kontrola-interakce-efekty“. Nejprve _zkontroluje_, zda jsou splněny podmínky nutné pro provedení (tj. zda má uživatel kladný zůstatek ETH), a provede _interakci_ odesláním ETH na adresu volajícího, než aplikuje _efekty_ transakce (tj. sníží zůstatek uživatele). -Pokud je funkce `withdraw()` volána z účtu vlastněného externí osobou (EOA), funkce se provede podle očekávání: `msg.sender.call.value()` odešle ETH volajícímu. Avšak pokud je `msg.sender` účet smart kontraktu, který volá `withdraw()`, odeslání prostředků pomocí `msg.sender.call.value()` spustí i kód uložený na této adrese. +Pokud je `withdraw()` volána z externě vlastněného účtu (EOA), funkce se provede podle očekávání: `msg.sender.call.value()` odešle ETH volajícímu. Pokud je však `msg.sender` účet chytrého kontraktu a volá `withdraw()`, odeslání prostředků pomocí `msg.sender.call.value()` spustí také kód uložený na této adrese. Představte si, že toto je kód na adrese kontraktu: @@ -289,28 +289,28 @@ Tento kontrakt je navržen tak, aby dělal tři věci: 2. Uložil 1 ETH do kontraktu Victim 3. Vybral 1 ETH uložený ve smart kontraktu -Na první pohled není na tomto kontraktu nic špatného, až na to, že kontrakt `Attacker` má další funkci, která znovu volá `withdraw()` v kontraktu `Victim`, pokud je zbývající palivo (gas) z příchozího volání `msg.sender.call.value` více než 40 000. To dává kontraktu `Attacker` schopnost znovu vstoupit do kontraktu `Victim` a vybrat více prostředků _před tím_, než se dokončí první volání `withdraw`. Tento cyklus vypadá následovně: +Není na tom nic špatného, kromě toho, že `Attacker` má další funkci, která znovu volá `withdraw()` v `Victim`, pokud je zbývající gas z příchozího `msg.sender.call.value` více než 40 000. To dává `Attackerovi` schopnost znovu vstoupit do `Victim` a vybrat více prostředků _před_ dokončením prvního volání `withdraw`. Tento cyklus vypadá následovně: ```solidity -- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH -- `Attacker.beginAttack()` deposits 1 ETH into `Victim` -- `Attacker` calls `withdraw() in `Victim` -- `Victim` checks `Attacker`’s balance (1 ETH) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function) -- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal) -- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function) -- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals -- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0 +- EOA útočníka volá `Attacker.beginAttack()` s 1 ETH +- `Attacker.beginAttack()` vloží 1 ETH do `Victim` +- `Attacker` volá `withdraw()` v `Victim` +- `Victim` zkontroluje zůstatek `Attacker` (1 ETH) +- `Victim` pošle 1 ETH `Attackerovi` (což spustí výchozí funkci) +- `Attacker` znovu volá `Victim.withdraw()` (všimněte si, že `Victim` nesnížil zůstatek `Attacker` z prvního výběru) +- `Victim` zkontroluje zůstatek `Attacker` (který je stále 1 ETH, protože neaplikoval efekty prvního volání) +- `Victim` pošle 1 ETH `Attackerovi` (což spustí výchozí funkci a umožní `Attackerovi` znovu vstoupit do funkce `withdraw`) +- Proces se opakuje, dokud `Attackerovi` nedojde gas, v tu chvíli `msg.sender.call.value` vrátí hodnotu bez spuštění dalších výběrů +- `Victim` nakonec aplikuje výsledky první transakce (a následujících) na svůj stav, takže zůstatek `Attacker` je nastaven na 0 ``` -Výsledkem je, že následná vyvolání budou úspěšná a umožní volajícímu vybrat svůj zůstatek vícekrát, protože zůstatek volajícího není nastaven na 0, dokud se nedokončí provedení funkce. Tento druh útoku může být použit k vybrání prostředků smart kontraktu, jako se to stalo při [DAO hacku v roce 2016](https://www.coindesk.com/learn/understanding-the-dao-attack). Útoky opětovným vstupem (reentrancy) jsou stále kritickým problémem smart kontraktů, jak ukazují [veřejné seznamy exploitů reentrancy útoků](https://github.com/pcaversaccio/reentrancy-attacks). +Výsledkem je, že následná vyvolání budou úspěšná a umožní volajícímu vybrat svůj zůstatek vícekrát, protože zůstatek volajícího není nastaven na 0, dokud se nedokončí provedení funkce. Tento druh útoku může být použit k vyčerpání prostředků z chytrého kontraktu, jako se to stalo při [hacku DAO v roce 2016](https://www.coindesk.com/learn/understanding-the-dao-attack). Útoky opětovným vstupem (reentrancy) jsou pro chytré kontrakty stále kritickým problémem, jak ukazují [veřejné seznamy zneužití reentrancy útoků](https://github.com/pcaversaccio/reentrancy-attacks). ##### Jak zabránit útokům opětovným vstupem -Jedním z přístupů, jak se vypořádat s reentrancy útoky, je dodržovat vzor [kontroly-efekty-interakce](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern). Tento vzor uspořádává provádění funkcí takovým způsobem, že kód, který provádí nezbytné kontroly před pokračováním v exekuci, je proveden jako první, následovaný kódem, který manipuluje se stavem kontraktu, a kód, který interaguje s jinými kontrakty nebo EOA, přichází na řadu jako poslední. +Přístupem k řešení opětovného vstupu je dodržování vzoru [kontrola-efekty-interakce](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern). Tento vzor uspořádává provádění funkcí takovým způsobem, že kód, který provádí nezbytné kontroly před pokračováním v exekuci, je proveden jako první, následovaný kódem, který manipuluje se stavem kontraktu, a kód, který interaguje s jinými kontrakty nebo EOA, přichází na řadu jako poslední. -Vzor kontroly-efekty-interakce je použit v revidované verzi kontraktu `Victim`, která je uvedena níže: +Vzor kontrola-efekty-interakce je použit v revidované verzi kontraktu `Victim`, která je uvedena níže: ```solidity contract NoLongerAVictim { @@ -323,9 +323,9 @@ contract NoLongerAVictim { } ``` -Tento kontrakt provádí _kontrolu_ zůstatku uživatele, aplikuje _efekty_ funkce `withdraw()` (nastavením zůstatku uživatele na 0) a poté pokračuje v _interakci_ (odesláním ETH na uživatelovu adresu). Tímto způsobem kontrakt aktualizuje svůj stav před externím voláním, čímž eliminuje podmínku opětovného vstupu, která umožňovala původní útok. Kontrakt `Attacker` stále může znovu volat funkci `withdraw()` v kontraktu `NoLongerAVictim`, ale protože `balances[msg.sender]` byla nastavena na 0, pokus o opětovné výběry by vyvolal chybu. +Tento kontrakt provádí _kontrolu_ zůstatku uživatele, aplikuje _efekty_ funkce `withdraw()` (nastavením zůstatku uživatele na 0) a poté pokračuje v _interakci_ (odesláním ETH na adresu uživatele). Tímto způsobem kontrakt aktualizuje svůj stav před externím voláním, čímž eliminuje podmínku opětovného vstupu, která umožňovala původní útok. Kontrakt `Attacker` by stále mohl znovu volat do `NoLongerAVictim`, ale protože `balances[msg.sender]` byla nastavena na 0, další výběry vyvolají chybu. -Další možností je použití zámku pro vzájemné vyloučení (běžně označovaného jako „mutex“), který uzamkne část stavu kontraktu, dokud se nedokončí volání funkce. To je implementováno pomocí proměnné typu Boolean, která je nastavena na `true` před provedením funkce a po dokončení volání se vrací na hodnotu `false`. Jak je vidět v níže uvedeném příkladu, použití mutexu chrání funkci před rekurzivními voláními, zatímco původní volání je stále zpracováváno, což účinně zastavuje reentrancy. +Další možností je použití zámku pro vzájemné vyloučení (běžně označovaného jako „mutex“), který uzamkne část stavu kontraktu, dokud se nedokončí volání funkce. To je implementováno pomocí booleovské proměnné, která je nastavena na `true` před provedením funkce a po dokončení volání se vrací na hodnotu `false`. Jak je vidět v níže uvedeném příkladu, použití mutexu chrání funkci před rekurzivními voláními, zatímco původní volání je stále zpracováváno, což účinně zastavuje reentrancy. ```solidity pragma solidity ^0.7.0; @@ -340,8 +340,8 @@ contract MutexPattern { _; locked = false; } - // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. - // Příkaz 'return' se vyhodnotí jako 'true', ale stále vyhodnocuje příkaz 'locked = false' v modifikátoru. + // Tato funkce je chráněna mutexem, takže reentrantní volání z `msg.sender.call` nemohou znovu volat `withdraw`. + // Příkaz `return` se vyhodnotí jako `true`, ale stále vyhodnocuje příkaz `locked = false` v modifikátoru function withdraw(uint _amount) public payable noReentrancy returns(bool) { require(balances[msg.sender] >= _amount, "No balance to withdraw."); @@ -354,32 +354,32 @@ contract MutexPattern { } ``` -Můžete také použít systém [pull payments](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment), který vyžaduje, aby sami uživatelé vybrali prostředky ze smart kontraktů, namísto systému „push payments“, který prostředky na účty odesílá sám. Tím se eliminuje možnost neúmyslného spuštění kódu na neznámých adresách (a může také zabránit určitým útokům typu denial-of-service). +Můžete také použít systém [pull payments](https://docs.openzeppelin.com/contracts/5.x/api/security#PullPayment), který vyžaduje, aby si uživatelé vybírali prostředky z chytrých kontraktů, namísto systému „push payments“, který prostředky na účty odesílá. Tím se eliminuje možnost neúmyslného spuštění kódu na neznámých adresách (a může také zabránit určitým útokům typu denial-of-service). -#### Přetečení a podtečení celých čísel {#integer-underflows-and-overflows} +#### Celočíselné podtečení a přetečení {#integer-underflows-and-overflows} -Přetečení celého čísla nastává, když výsledek aritmetické operace překročí přijatelný rozsah hodnot, což způsobí „přetočení“ na nejnižší reprezentovatelnou hodnotu. Například `uint8` může uložit hodnoty až do 2^8-1=255. Aritmetické operace, které vedou k hodnotám vyšším než `255`, přetečou a nastaví `uint` na `0`, podobně jako se tachometr automobilu resetuje na 0, když dosáhne maximálního nájezdu (999999). +Přetečení celého čísla nastává, když výsledek aritmetické operace překročí přijatelný rozsah hodnot, což způsobí „přetočení“ na nejnižší reprezentovatelnou hodnotu. Například `uint8` může ukládat pouze hodnoty do 2^8-1=255. Aritmetické operace, které vedou k hodnotám vyšším než `255`, přetečou a resetují `uint` na `0`, podobně jako se počítadlo kilometrů v autě resetuje na 0, když dosáhne maximálního nájezdu (999999). -Podtečení celého čísla se děje ze stejných důvodů: výsledek aritmetické operace klesne pod přijatelný rozsah. Pokud byste například zkusili snížit hodnotu `0` v `uint8`, výsledek by se jednoduše přetočil na maximální reprezentovatelnou hodnotu (`255`). +Podtečení celého čísla se děje ze stejných důvodů: výsledek aritmetické operace klesne pod přijatelný rozsah. Řekněme, že byste se pokusili snížit `0` v `uint8`, výsledek by se jednoduše přetočil na maximální reprezentovatelnou hodnotu (`255`). Přetečení i podtečení celých čísel může vést k neočekávaným změnám proměnných stavu kontraktu a způsobit neplánovanou exekuci. Níže je uveden příklad, jak může útočník zneužít aritmetické přetečení ve smart kontraktu k provedení neplatné operace: ``` pragma solidity ^0.7.6; -// This contract is designed to act as a time vault. -// User can deposit into this contract but cannot withdraw for at least a week. -// User can also extend the wait time beyond the 1 week waiting period. +// Tento kontrakt je navržen tak, aby fungoval jako časový trezor. +// Uživatel může do tohoto kontraktu vkládat, ale nemůže vybírat po dobu nejméně jednoho týdne. +// Uživatel může také prodloužit čekací dobu nad 1 týden čekací lhůty. /* -1. Deploy TimeLock -2. Deploy Attack with address of TimeLock -3. Call Attack.attack sending 1 ether. You will immediately be able to - withdraw your ether. - -What happened? -Attack caused the TimeLock.lockTime to overflow and was able to withdraw -before the 1 week waiting period. +1. Nasaďte TimeLock +2. Nasaďte Attack s adresou TimeLock +3. Zavolejte Attack.attack a pošlete 1 ether. Budete moci okamžitě vybrat + svůj ether. + +Co se stalo? +Attack způsobil přetečení TimeLock.lockTime a byl schopen vybrat +před uplynutím 1týdenní čekací doby. */ contract TimeLock { @@ -435,15 +435,15 @@ contract Attack { ##### Jak zabránit podtečení a přetečení celých čísel -Od verze 0.8.0 kompilátor Solidity odmítá kód, který by vedl k podtečení nebo přetečení celých čísel. A smart kontrakty, které jsou kompilovány pomocí starší verze kompilátoru, by měly buď provádět kontroly ve funkcích zahrnujících aritmetické operace, nebo použít knihovnu (např. [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)), která provádí kontroly podtečení/přetečení. +Od verze 0.8.0 kompilátor Solidity odmítá kód, který by vedl k podtečení nebo přetečení celých čísel. Kontrakty kompilované nižší verzí kompilátoru by však měly buď provádět kontroly funkcí zahrnujících aritmetické operace, nebo používat knihovnu (např. [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)), která kontroluje podtečení/přetečení. -#### Manipulace s orákly {#oracle-manipulation} +#### Manipulace s orákulem {#oracle-manipulation} -[Orákula](/developers/docs/oracles/) získávají informace mimo blockchain a posílají je do něj, kde je mohou použít chytré kontrakty. Pomocí orákul můžete navrhovat chytré kontrakty, které spolupracují se systémy mimo blockchain, jako jsou kapitálové trhy, což výrazně rozšiřuje jejich využití. +[Orákula](/developers/docs/oracles/) získávají informace mimo blockchain a posílají je na blockchain, kde je mohou použít chytré kontrakty. Pomocí orákul můžete navrhovat chytré kontrakty, které spolupracují se systémy mimo blockchain, jako jsou kapitálové trhy, což výrazně rozšiřuje jejich využití. Pokud je však orákulum poškozeno a posílá nesprávné informace na blockchain, kód chytrých kontraktů bude vykonáván na základě chybných vstupů, což může způsobit problémy. To je podstatou „problému orákulí“, který se týká úkolu zajistit, aby informace z blockchainového orákula byly přesné, aktuální a včasné. -Souvisejícím bezpečnostním problémem je použití orákula na blockchainu, například decentralizované burzy, k získání aktuální ceny aktiva. Platformy na půjčování prostředků v odvětví [decentralizovaných financí (DeFi)](/defi/) to často dělají, aby určily hodnotu zástavy uživatele a zjistily, kolik si může půjčit. +Souvisejícím bezpečnostním problémem je použití orákula na blockchainu, například decentralizované burzy, k získání aktuální ceny aktiva. Půjčovací platformy v odvětví [decentralizovaných financí (DeFi)](/defi/) to často dělají, aby určily hodnotu zástavy uživatele a zjistily, kolik si může půjčit. Ceny na DEX jsou často přesné, zejména díky arbitrážím, které obnovují paritu na trzích. Je však možné s nimi manipulovat, zejména pokud orákulum na blockchainu vypočítává ceny aktiv na základě historických obchodních vzorců (což se obvykle stává). @@ -451,126 +451,126 @@ Ceny na DEX jsou často přesné, zejména díky arbitrážím, které obnovují ##### Jak zabránit manipulaci s orákly -Minimálním požadavkem na [zabránění manipulaci s orákly](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) je použití decentralizované sítě orákulí, která dotazuje informace z více zdrojů, aby se zabránilo jednotlivým bodům selhání. Ve většině případů mají decentralizovaná orákula vestavěné kryptoekonomické pobídky, které motivují orákulové uzly k hlášení správných informací, což je činí bezpečnějšími než centralizovaná orákula. +Minimálním požadavkem, jak se [vyhnout manipulaci s orákulem](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples), je použití decentralizované sítě orákul, která dotazuje informace z více zdrojů, aby se zabránilo jednotlivým bodům selhání. Ve většině případů mají decentralizovaná orákula vestavěné kryptoekonomické pobídky, které motivují orákulové uzly k hlášení správných informací, což je činí bezpečnějšími než centralizovaná orákula. Pokud plánujete dotazovat se blockchainového orákula na ceny aktiv, zvažte použití takového systému, který implementuje mechanismus časově vážené průměrné ceny (TWAP). [TWAP orákulum](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) dotazuje cenu aktiva ve dvou různých časových bodech (které můžete upravit) a vypočítá spotovou cenu na základě získaného průměru. Volba delších časových období chrání váš protokol proti manipulaci s cenami, protože velké objednávky provedené nedávno nemohou ovlivnit ceny aktiv. -## Zdroje pro zabezpečení smart kontraktů pro vývojáře {#smart-contract-security-resources-for-developers} +## Zdroje pro zabezpečení chytrých kontraktů pro vývojáře {#smart-contract-security-resources-for-developers} -### Nástroje pro analýzu smart kontraktů a ověřování správnosti kódu {#code-analysis-tools} +### Nástroje pro analýzu chytrých kontraktů a ověřování správnosti kódu {#code-analysis-tools} -- **[Testovací nástroje a knihovny](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** – _sbírka profesionálních nástrojů a knihoven pro provádění unit testů, statické analýzy a dynamické analýzy na smart kontraktech._ +- **[Testovací nástroje a knihovny](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** – _Sbírka standardních nástrojů a knihoven pro provádění jednotkových testů, statické analýzy a dynamické analýzy na chytrých kontraktech._ -- **[Nástroje pro formální ověřování](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** – _nástroje pro ověřování funkční správnosti ve smart kontraktech a kontrolu invariantů._ +- **[Nástroje pro formální ověření](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** – _Nástroje pro ověřování funkční správnosti v chytrých kontraktech a kontrolu invariantů._ -- **[Služby auditu smart kontraktů](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** – _seznam organizací poskytujících služby auditu smart kontraktů pro vývojové projekty Etherea._ +- **[Služby auditu chytrých kontraktů](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** – _Seznam organizací poskytujících služby auditu chytrých kontraktů pro vývojové projekty na Ethereu._ -- **[Platformy na odměny za řešení chyb](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** – _platformy pro koordinaci odměn za řešení chyb a odměňování odpovědného odhalování kritických zranitelností ve smart kontraktech._ +- **[Platformy pro odměny za nalezení chyb](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** – _Platformy pro koordinaci odměn za nalezení chyb a odměňování za zodpovědné odhalování kritických zranitelností v chytrých kontraktech._ -- **[Kontrola forku](https://forkchecker.hashex.org/)** – _bezplatný online nástroj pro kontrolu všech dostupných informací o forkovaném kontraktu._ +- **[Fork Checker](https://forkchecker.hashex.org/)** – _bezplatný online nástroj pro kontrolu všech dostupných informací o forkovaném kontraktu._ -- **[ABI Kodér](https://abi.hashex.org/)** – _bezplatná online služba pro kódování funkcí a argumentů konstruktorů kontraktů Solidity._ +- **[ABI Encoder](https://abi.hashex.org/)** – _bezplatná online služba pro kódování funkcí a argumentů konstruktorů vašich kontraktů v Solidity._ -- **[Aderyn](https://github.com/Cyfrin/aderyn)** – _statický analyzér Solidity, který prochází abstraktní syntaktické stromy (AST) za účelem zjištění podezřelých zranitelností a vypisuje problémy v přehledném markdown formátu._ +- **[Aderyn](https://github.com/Cyfrin/aderyn)** – _Statický analyzátor pro Solidity, který prochází abstraktní syntaktické stromy (AST), aby odhalil podezřelé zranitelnosti a zobrazil problémy v přehledném formátu markdown._ -### Nástroje pro monitorování smart kontraktů {#smart-contract-monitoring-tools} +### Nástroje pro monitorování chytrých kontraktů {#smart-contract-monitoring-tools} -- **[Tenderly Real-Time Alerting](https://tenderly.co/alerting/)** – _nástroj pro získávání oznámení v reálném čase, když dojde k neobvyklým nebo neočekávaným událostem ve vašich smart kontraktech nebo peněženkách._ +- **[Tenderly Real-Time Alerting](https://tenderly.co/monitoring)** – _nástroj pro získávání oznámení v reálném čase, když dojde k neobvyklým nebo neočekávaným událostem ve vašich chytrých kontraktech nebo peněženkách._ -### Nástroje pro bezpečnou správu smart kontraktů {#smart-contract-administration-tools} +### Nástroje pro bezpečnou správu chytrých kontraktů {#smart-contract-administration-tools} -- **[Safe](https://safe.global/)** – _peněženka se smart kontraktem běžící na platformě Ethereum, která vyžaduje, aby transakci schválil minimální počet lidí (M-z-N)._ +- **[Safe](https://safe.global/)** – _Peněženka s chytrým kontraktem běžící na Ethereu, která vyžaduje, aby transakci schválil minimální počet lidí (M z N), než může proběhnout._ -- **[Kontrakty OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/)** – _knihovny kontraktů pro implementaci funkcí správy, včetně vlastnictví kontraktů, upgradů, řízení přístupu, správy, možnosti pozastavení a více._ +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/5.x/)** – _Knihovny kontraktů pro implementaci administrativních funkcí, včetně vlastnictví kontraktů, upgradů, řízení přístupu, správy, možnosti pozastavení a dalších._ -### Služby auditu smart kontraktů {#smart-contract-auditing-services} +### Služby auditu chytrých kontraktů {#smart-contract-auditing-services} -- **[ConsenSys Diligence](https://consensys.net/diligence/)** – _služba auditu smart kontraktů, která pomáhá projektům napříč blockchainovým ekosystémem zajistit, aby jejich protokoly byly připraveny ke spuštění a vytvořeny tak, aby chránily uživatele._ +- **[ConsenSys Diligence](https://diligence.consensys.io/)** – _Služba auditu chytrých kontraktů, která pomáhá projektům napříč blockchainovým ekosystémem zajistit, aby jejich protokoly byly připraveny ke spuštění a vytvořeny tak, aby chránily uživatele._ -- **[CertiK](https://www.certik.com/)** – _blockchainová bezpečnostní firma, která je průkopníkem v používání nejmodernější technologie formálního ověřování ve smart kontraktech a blockchainových sítích._ +- **[CertiK](https://www.certik.com/)** – _Blockchainová bezpečnostní firma, která je průkopníkem v používání nejmodernější technologie formálního ověřování na chytrých kontraktech a blockchainových sítích._ -- **[Trail of Bits](https://www.trailofbits.com/)** – _společnost zabývající se kybernetickou bezpečností, která kombinuje bezpečnostní výzkum s mentalitou útočníka s cílem snížit riziko a posílit kód._ +- **[Trail of Bits](https://www.trailofbits.com/)** – _Společnost zabývající se kybernetickou bezpečností, která kombinuje bezpečnostní výzkum s mentalitou útočníka s cílem snížit riziko a posílit kód._ -- **[PeckShield](https://peckshield.com/)** – _blockchainová bezpečnostní společnost nabízející produkty a služby pro bezpečnost, soukromí a použitelnost celého blockchainového ekosystému._ +- **[PeckShield](https://peckshield.com/)** – _Blockchainová bezpečnostní společnost nabízející produkty a služby pro bezpečnost, soukromí a použitelnost celého blockchainového ekosystému._ -- **[QuantStamp](https://quantstamp.com/)** – _auditorská služba usnadňující mainstreamové přijetí blockchainové technologie prostřednictvím služeb hodnocení bezpečnosti a rizik._ +- **[QuantStamp](https://quantstamp.com/)** – _Auditorská služba usnadňující masové přijetí blockchainové technologie prostřednictvím služeb hodnocení bezpečnosti a rizik._ -- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** – _bezpečnostní společnost zabývající se smart kontrakty poskytující bezpečnostní audity pro distribuované systémy._ +- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** – _Bezpečnostní společnost zabývající se chytrými kontrakty poskytující bezpečnostní audity pro distribuované systémy._ -- **[Runtime Verification](https://runtimeverification.com/)** – _bezpečnostní společnost specializující se na formální modelování a ověřování smart kontraktů._ +- **[Runtime Verification](https://runtimeverification.com/)** – _Bezpečnostní společnost specializující se na formální modelování a ověřování chytrých kontraktů._ -- **[Hacken](https://hacken.io)** – _Web3 auditor kybernetické bezpečnosti přinášející 360stupňový přístup k bezpečnosti blockchainu._ +- **[Hacken](https://hacken.io)** – _Auditor kybernetické bezpečnosti pro Web3, který přináší 360stupňový přístup k bezpečnosti blockchainu._ -- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** – _služby auditu Solidity a Cairo, které zajišťují integritu smart kontraktů a bezpečnost uživatelů napříč Ethereem a Starknetem._ +- **[Nethermind](https://www.nethermind.io/smart-contract-audits)** – _Služby auditu v Solidity a Cairo, které zajišťují integritu chytrých kontraktů a bezpečnost uživatelů na Ethereu a Starknetu._ -- **[HashEx](https://hashex.org/)** – _HashEx se zaměřuje na audit blockchainu a smart kontraktů s cílem zajistit bezpečnost kryptoměn a poskytuje služby, jako je vývoj smart kontraktů, penetrační testování a poradenství v oblasti blockchainu._ +- **[HashEx](https://hashex.org/)** – _HashEx se zaměřuje na audit blockchainu a chytrých kontraktů s cílem zajistit bezpečnost kryptoměn a poskytuje služby, jako je vývoj chytrých kontraktů, penetrační testování a poradenství v oblasti blockchainu._ -- **[Code4rena](https://code4rena.com/)** – _kompetitivní platforma pro audit, která motivuje experty na zabezpečení smart kontraktů, aby našli zranitelnosti a pomohli zvýšit bezpečnost webu3._ +- **[Code4rena](https://code4rena.com/)** – _Soutěžní platforma pro audit, která motivuje experty na zabezpečení chytrých kontraktů, aby našli zranitelnosti a pomohli zvýšit bezpečnost webu3._ -- **[CodeHawks](https://codehawks.com/)** – _kompetitivní platforma pro auditování smart kontraktů pořádající soutěže pro výzkumníky v oblasti bezpečnosti._ +- **[CodeHawks](https://codehawks.com/)** – _Soutěžní platforma pro auditování, která pořádá soutěže v auditování chytrých kontraktů pro bezpečnostní výzkumníky._ -- **[Cyfrin](https://cyfrin.io)** – _bezpečnostní Web3 společnost, inkubátor krypto bezpečnosti prostřednictvím produktů a služeb auditu smart kontraktů._ +- **[Cyfrin](https://cyfrin.io)** – _Lídr v oblasti zabezpečení Web3, inkubátor krypto bezpečnosti prostřednictvím produktů a služeb auditu chytrých kontraktů._ -- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** – _Web3 bezpečnostní firma nabízející bezpečnostní audity pro blockchainové systémy prostřednictvím týmu zkušených auditorů a nejlepších nástrojů ve své třídě._ +- **[ImmuneBytes](https://immunebytes.com/smart-contract-audit/)** – _Bezpečnostní firma pro Web3 nabízející bezpečnostní audity pro blockchainové systémy prostřednictvím týmu zkušených auditorů a nejlepších nástrojů ve své třídě._ -- **[Oxorio](https://oxor.io/)** – _audity smart kontraktů a bezpečnostní služby blockchainu s odbornými znalostmi v oblasti EVM, Solidity, ZK, technologií napříč blockchainy pro krypto firmy a projekty DeFi._ +- **[Oxorio](https://oxor.io/)** – _Audity chytrých kontraktů a bezpečnostní služby blockchainu s odbornými znalostmi v oblasti EVM, Solidity, ZK, cross-chain technologií pro krypto firmy a projekty DeFi._ -- **[Inference](https://inference.ag/)** – _bezpečnostní auditorská společnost, která se specializuje na audit smart kontraktů pro blockchainy založené na EVM. Díky svým odborným auditorům identifikují potenciální problémy a navrhují schůdná řešení k jejich odstranění ještě před nasazením._ +- **[Inference](https://inference.ag/)** – _Bezpečnostní auditorská společnost, která se specializuje na audit chytrých kontraktů pro blockchainy založené na EVM. Díky svým odborným auditorům identifikují potenciální problémy a navrhují schůdná řešení k jejich odstranění ještě před nasazením._ -### Platformy pro odměny za řešení chyb {#bug-bounty-platforms} +### Platformy pro odměny za nalezení chyb {#bug-bounty-platforms} -- **[Immunefi](https://immunefi.com/)** – _platforma na odměny za řešení chyb ve smart kontraktech a projektech DeFi, kde bezpečnostní výzkumníci revidují kód, odhalují zranitelnosti, dostávají zaplaceno a zvyšují bezpečnost kryptoměn._ +- **[Immunefi](https://immunefi.com/)** – _Platforma pro odměny za nalezení chyb ve chytrých kontraktech a projektech DeFi, kde bezpečnostní výzkumníci revidují kód, odhalují zranitelnosti, dostávají zaplaceno a zvyšují bezpečnost kryptoměn._ -- **[HackerOne](https://www.hackerone.com/)** – _platforma pro koordinaci zranitelností a odměny za chyby, která spojuje podniky s testery penetrací a výzkumníky kybernetické bezpečnosti._ +- **[HackerOne](https://www.hackerone.com/)** – _Platforma pro koordinaci zranitelností a odměn za nalezení chyb, která spojuje podniky s testery penetrací a výzkumníky kybernetické bezpečnosti._ -- **[HackenProof](https://hackenproof.com/)** – _expertní platforma na odměny za řešení chyb pro krypto projekty (DeFi, smart kontrakty, peněženky, CEX a další), kde bezpečnostní profesionálové poskytují služby třídění a výzkumníci dostávají zaplaceno za relevantní, ověřená hlášení chyb._ +- **[HackenProof](https://hackenproof.com/)** – _Expertní platforma pro odměny za nalezení chyb pro krypto projekty (DeFi, chytré kontrakty, peněženky, CEX a další), kde bezpečnostní profesionálové poskytují služby třídění a výzkumníci dostávají zaplaceno za relevantní, ověřená hlášení chyb._ -- **[Sherlock](https://www.sherlock.xyz/)** – _ručitel ve Web3 pro zabezpečení smart kontraktů, s výplatami pro auditory řízenými prostřednictvím smart kontraktů, aby se zajistilo, že příslušné chyby budou spravedlivě zaplaceny._ +- **[Sherlock](https://www.sherlock.xyz/)** – _Pojistitel ve Web3 pro zabezpečení chytrých kontraktů, s výplatami pro auditory řízenými prostřednictvím chytrých kontraktů, aby se zajistilo, že relevantní chyby budou spravedlivě zaplaceny._ -- **[CodeHawks](https://www.codehawks.com/)** – _kompetitivní platforma na odměny za řešení chyb, kde se auditoři účastní bezpečnostních soutěží a výzev a (brzy) i vlastních soukromých auditů._ +- **[CodeHawks](https://www.codehawks.com/)** – _Soutěžní platforma pro odměny za nalezení chyb, kde se auditoři účastní bezpečnostních soutěží a výzev a (brzy) i vlastních soukromých auditů._ -### Publikace známých zranitelností a zneužití smart kontraktů {#common-smart-contract-vulnerabilities-and-exploits} +### Publikace známých zranitelností a zneužití chytrých kontraktů {#common-smart-contract-vulnerabilities-and-exploits} -- **[ConsenSys: Známé útoky na smart kontrakty](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** – _vysvětlení pro začátečníky nejvýznamnějších zranitelností smluv s ukázkovým kódem pro většinu případů._ +- **[ConsenSys: Známé útoky na chytré kontrakty](https://consensysdiligence.github.io/smart-contract-best-practices/attacks/)** – _Vysvětlení nejvýznamnějších zranitelností kontraktů pro začátečníky, s ukázkovým kódem pro většinu případů._ -- **[Registr SWC](https://swcregistry.io/)** – _souborný seznam položek Common Weakness Enumeration (CWE, enumerací častých slabin), které se vztahují na smart kontrakty Etherea._ +- **[SWC Registry](https://swcregistry.io/)** – _Kurátorovaný seznam položek Common Weakness Enumeration (CWE), které se vztahují na chytré kontrakty Etherea._ -- **[Rekt](https://rekt.news/)** – _pravidelně aktualizovaná publikace významných krypto hacků a exploitů spolu s podrobnými postmortálními zprávami._ +- **[Rekt](https://rekt.news/)** – _Pravidelně aktualizovaná publikace významných krypto hacků a zneužití, spolu s podrobnými post-mortem zprávami._ -### Výzvy určené k učení se zabezpečení smart kontraktů {#challenges-for-learning-smart-contract-security} +### Výzvy pro učení se zabezpečení chytrých kontraktů {#challenges-for-learning-smart-contract-security} -- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** – _kurátorský seznam blockchainových bezpečnostních válečných her, výzev a [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) soutěží a zápisů řešení._ +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** – _Kurátorovaný seznam blockchainových bezpečnostních válečných her, výzev a soutěží [Capture The Flag](https://www.webopedia.com/definitions/ctf-event/amp/) a řešení._ -- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** – _válečná hra, ve které se naučíte ofensivní zabezpečení smart kontraktů DeFi a získáte dovednosti v oblasti hledání chyb a bezpečnostního auditu._ +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** – _Válečná hra, ve které se naučíte útočnou bezpečnost chytrých kontraktů DeFi a získáte dovednosti v oblasti hledání chyb a bezpečnostního auditu._ -- **[Ethernaut](https://ethernaut.openzeppelin.com/)** – _Web3/Solidity válečná hra, kde každá úroveň představuje smart kontrakt, který je třeba „hacknout“._ +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** – _Válečná hra založená na Web3/Solidity, kde každá úroveň představuje chytrý kontrakt, který je třeba „hacknout“._ -- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** – _hackovací výzvy smart kontraktů, zasazená do fantasy dobrodružství. Úspěšné splnění výzvy také umožňuje přístup do soukromého programu odměn za řešení chyb._ +- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** – _Výzva v hackování chytrých kontraktů, zasazená do fantasy dobrodružství. Úspěšné splnění výzvy také umožňuje přístup do soukromého programu odměn za řešení chyb._ -### Osvědčené postupy pro zabezpečení smart kontraktů {#smart-contract-security-best-practices} +### Osvědčené postupy pro zabezpečení chytrých kontraktů {#smart-contract-security-best-practices} -- **[ConsenSys: ](https://consensys.github.io/smart-contract-best-practices/)** – _Úplný seznam pokynů pro zabezpečení smart kontraktů na Ethereu._ +- **[ConsenSys: Osvědčené postupy pro bezpečnost chytrých kontraktů na Ethereu](https://consensys.github.io/smart-contract-best-practices/)** – _Komplexní seznam pokynů pro zabezpečení chytrých kontraktů na Ethereu._ -- **[Nascent: Jednoduchý bezpečnostní toolkit](https://github.com/nascentxyz/simple-security-toolkit)** – _sbírka praktických průvodců a kontrolních seznamů zaměřených na bezpečnost při vývoji smart kontraktů._ +- **[Nascent: Jednoduchý bezpečnostní toolkit](https://github.com/nascentxyz/simple-security-toolkit)** – _Sbírka praktických průvodců a kontrolních seznamů zaměřených na bezpečnost při vývoji chytrých kontraktů._ -- **[Solidity Patterns](https://fravoll.github.io/solidity-patterns/)** – _užitečná kompilace bezpečných vzorů a osvědčených postupů pro programovací jazyk smart kontraktů Solidity._ +- **[Vzory v Solidity](https://fravoll.github.io/solidity-patterns/)** – _Užitečná kompilace bezpečných vzorů a osvědčených postupů pro programovací jazyk chytrých kontraktů Solidity._ -- **[Dokumenty Solidity: Security Considerations](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** – _pokyny pro psaní bezpečných smart kontraktů pomocí Solidity._ +- **[Dokumentace Solidity: Bezpečnostní aspekty](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** – _Pokyny pro psaní bezpečných chytrých kontraktů v Solidity._ -- **[Standard ověřování zabezpečení smart kontraktů](https://github.com/securing/SCSVS)** – _čtrnáctidílný kontrolní seznam vytvořený za účelem standardizace zabezpečení smart kontraktů pro vývojáře, architekty, bezpečnostní recenzenty a prodejce._ +- **[Standard ověřování bezpečnosti chytrých kontraktů](https://github.com/securing/SCSVS)** – _Čtrnáctidílný kontrolní seznam vytvořený za účelem standardizace zabezpečení chytrých kontraktů pro vývojáře, architekty, bezpečnostní recenzenty a prodejce._ -- **[Učte se zabezpečení a auditování chytrých kontraktů](https://updraft.cyfrin.io/courses/security)** – _Ultimátní kurz bezpečnosti a auditu chytrých kontraktů vytvořený pro vývojáře chytrých kontraktů, kteří chtějí zvýšit úroveň svých osvědčených postupů v oblasti bezpečnosti a stát se bezpečnostními výzkumníky._ +- **[Učte se zabezpečení a auditování chytrých kontraktů](https://updraft.cyfrin.io/courses/security)** – _Komplexní kurz bezpečnosti a auditu chytrých kontraktů vytvořený pro vývojáře chytrých kontraktů, kteří chtějí zlepšit své osvědčené postupy v oblasti bezpečnosti a stát se bezpečnostními výzkumníky._ -### Výukové programy o zabezpečení smart kontraktů {#tutorials-on-smart-contract-security} +### Návody na zabezpečení chytrých kontraktů {#tutorials-on-smart-contract-security} -- [Jak psát bezpečné smart kontrakty](/developers/tutorials/secure-development-workflow/) +- [Jak psát bezpečné chytré kontrakty](/developers/tutorials/secure-development-workflow/) -- [Jak používat Slither k hledání chyb ve smart kontraktech](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [Jak používat Slither k nalezení chyb v chytrých kontraktech](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [Jak používat Manticore k vyhledávání chyb v chytrých kontraktech](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [Jak používat Manticore k nalezení chyb v chytrých kontraktech](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [Pokyny pro zabezpečení smart kontraktů](/developers/tutorials/smart-contract-security-guidelines/) +- [Pokyny pro bezpečnost chytrých kontraktů](/developers/tutorials/smart-contract-security-guidelines/) -- [Jak bezpečně integrovat tokenový kontrakt s libovolnými tokeny](/developers/tutorials/token-integration-checklist/) +- [Jak bezpečně integrovat váš tokenový kontrakt s libovolnými tokeny](/developers/tutorials/token-integration-checklist/) -- [Cyfrin Updraft – zabezpečení a auditování smart kontraktů, celý kurz](https://updraft.cyfrin.io/courses/security) +- [Cyfrin Updraft – kompletní kurz zabezpečení a auditu chytrých kontraktů](https://updraft.cyfrin.io/courses/security) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/testing/index.md b/public/content/translations/cs/developers/docs/smart-contracts/testing/index.md index f8689e2826f..72f6df96d81 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/testing/index.md @@ -1,38 +1,38 @@ --- -title: Testování chytrých smluv -description: Přehled technik a úvah využívaných při testování chytrých kontraktů na Ethereu. +title: "Testování chytrých kontraktů" +description: "Přehled technik a úvah využívaných při testování chytrých kontraktů na Ethereu." lang: cs --- -Veřejné blockchainy, jako je Ethereum, jsou neměnné, což ztěžuje změnu kódu chytrých kontraktů po nasazení. Existují [vzory vylepšení kontraktů](/developers/docs/smart-contracts/upgrading/) pro provádění „virtuálních vylepšení“, které se však obtížně implementují a vyžadují sociální konsenzus. Navíc vylepšení může chybu opravit až _po_ jejím objevení – pokud útočník objeví zranitelnost jako první, je váš chytrý kontrakt vystaven riziku zneužití. +Veřejné blockchainy, jako je Ethereum, jsou neměnné, což ztěžuje změnu kódu chytrých kontraktů po nasazení. [Vzory vylepšení kontraktů](/developers/docs/smart-contracts/upgrading/) pro provádění „virtuálních vylepšení“ existují, ale je obtížné je implementovat a vyžadují sociální konsensus. Navíc vylepšení může chybu opravit až po jejím objevení – pokud útočník objeví zranitelnost jako první, je váš chytrý kontrakt vystaven riziku zneužití. -Z těchto důvodů je testování chytrých kontraktů před [nasazením](/developers/docs/smart-contracts/deploying/) do hlavní sítě minimálním požadavkem na [bezpečnost](/developers/docs/smart-contracts/security/). Existuje mnoho technik pro testování kontraktů a vyhodnocování správnosti kódu; výběr závisí na vašich potřebách. Nicméně sada testů složená z různých nástrojů a přístupů je ideální pro odhalení menších i větších bezpečnostních chyb v kódu kontraktu. +Z těchto důvodů je testování chytrých kontraktů před [nasazením](/developers/docs/smart-contracts/deploying/) na hlavní síť minimálním požadavkem na [zabezpečení](/developers/docs/smart-contracts/security/). Existuje mnoho technik pro testování kontraktů a vyhodnocování správnosti kódu; výběr závisí na vašich potřebách. Nicméně sada testů složená z různých nástrojů a přístupů je ideální pro odhalení menších i větších bezpečnostních chyb v kódu kontraktu. ## Předpoklady {#prerequisites} -Tato stránka vysvětluje, jak testovat chytré kontrakty před nasazením do Etherea. Předpokládá, že rozumíte [chytrým kontraktům](/developers/docs/smart-contracts/). +Tato stránka vysvětluje, jak testovat chytré kontrakty před nasazením do Etherea. Předpokládá se, že jste obeznámeni s [chytrými kontrakty](/developers/docs/smart-contracts/). -## Co je to testování chytrého kontraktu? {#what-is-smart-contract-testing} +## Co je testování chytrých kontraktů? {#what-is-smart-contract-testing} Testování chytrých kontraktů je proces ověřování, zda kód chytrého kontraktu funguje podle očekávání. Testování je užitečné pro kontrolu, zda konkrétní chytrý kontrakt splňuje požadavky na spolehlivost, použitelnost a bezpečnost. Ačkoli se přístupy liší, většina metod testování vyžaduje spuštění chytrého kontraktu s malým vzorkem dat, který má zpracovávat. Pokud kontrakt poskytuje správné výsledky pro vzorková data, předpokládá se, že funguje správně. Většina testovacích nástrojů poskytuje prostředky pro psaní a provádění [testovacích případů](https://en.m.wikipedia.org/wiki/Test_case) ke kontrole, zda provedení kontraktu odpovídá očekávaným výsledkům. -### Proč je důležité testovat chytré kontrakty? {#importance-of-testing-smart-contracts} +### Proč je důležité testovat chytré kontrakty? Důležitost testování chytrých kontraktů {#importance-of-testing-smart-contracts} -Vzhledem k tomu, že chytré kontrakty často spravují finanční aktiva vysoké hodnoty, mohou drobné programátorské chyby často vést k [masivním ztrátám pro uživatele](https://rekt.news/leaderboard/). Důkladné testování vám však může pomoci včas odhalit chyby a problémy v kódu chytrého kontraktu a opravit je ještě před spuštěním na hlavní síti. +Vzhledem k tomu, že chytré kontrakty často spravují finanční aktiva vysoké hodnoty, mohou drobné programátorské chyby vést a často vedou k [masivním ztrátám pro uživatele](https://rekt.news/leaderboard/). Důkladné testování vám však může pomoci včas odhalit chyby a problémy v kódu chytrého kontraktu a opravit je ještě před spuštěním na hlavní síti. V případě objevení chyby je sice možné kontrakt vylepšit, ale vylepšení jsou složitá a při nesprávném postupu mohou [vést k chybám](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/). Vylepšení kontraktu dále popírá princip neměnnosti a zatěžuje uživatele dalšími předpoklady důvěryhodnosti. Komplexní plán testování kontraktu naopak zmírňuje bezpečnostní rizika a snižuje potřebu provádět po nasazení složité vylepšení logiky. ## Metody testování chytrých kontraktů {#methods-for-testing-smart-contracts} -Metody testování chytrých kontraktů na Ethereu spadají do dvou velkých kategorií: **automatizované testování** a **ruční testování**. Automatizované a ruční testování nabízejí jedinečné výhody a kompromisy, ale můžete je kombinovat a vytvořit tak robustní plán pro analýzu vašich kontraktů. +Metody testování chytrých kontraktů na Ethereu spadají do dvou širokých kategorií: **automatizované testování** a **ruční testování**. Automatizované a ruční testování nabízejí jedinečné výhody a kompromisy, ale můžete je kombinovat a vytvořit tak robustní plán pro analýzu vašich kontraktů. ### Automatizované testování {#automated-testing} -Automatizované testování využívá nástroje, které automaticky kontrolují kód chytrých kontraktů na chyby při provádění. Výhodou automatizovaného testování je možnost používání [skriptů](https://www.techtarget.com/whatis/definition/script?amp=1), které slouží k vyhodnocování funkcí kontraktu. Skriptované testy lze naplánovat tak, aby se opakovaně spouštěly s minimálním zásahem člověka, čímž je automatizované testování efektivnější než ruční přístup k testování. +Automatizované testování využívá nástroje, které automaticky kontrolují kód chytrých kontraktů na chyby při provádění. Výhoda automatizovaného testování spočívá v použití [skriptů](https://www.techtarget.com/whatis/definition/script?amp=1), které řídí vyhodnocování funkcionalit kontraktu. Skriptované testy lze naplánovat tak, aby se opakovaně spouštěly s minimálním zásahem člověka, čímž je automatizované testování efektivnější než ruční přístup k testování. -Automatizované testování je užitečné zejména v případech, kdy se testy opakují a jsou časově náročné; je obtížné je provádět ručně; jsou náchylné k lidským chybám; nebo zahrnují hodnocení kritických funkcí kontraktu. Automatické testovací nástroje však mohou mít i své nevýhody – mohou přehlédnout některé chyby a produkovat mnoho [falešně pozitivních výsledků](https://www.contrastsecurity.com/glossary/false-positive). Proto je ideální kombinovat automatizované testování s ručním testováním chytrých kontraktů. +Automatizované testování je užitečné zejména v případech, kdy se testy opakují a jsou časově náročné; je obtížné je provádět ručně; jsou náchylné k lidským chybám; nebo zahrnují hodnocení kritických funkcí kontraktu. Automatizované testovací nástroje ale mohou mít i nevýhody – mohou přehlédnout některé chyby a vygenerovat mnoho [falešně pozitivních výsledků](https://www.contrastsecurity.com/glossary/false-positive). Proto je ideální kombinovat automatizované testování s ručním testováním chytrých kontraktů. ### Ruční testování {#manual-testing} @@ -54,9 +54,9 @@ Jednotkové testy jsou užitečné pro kontrolu, zda funkce vracejí očekávan ##### 1. Pochopte obchodní logiku a pracovní postupy vašich kontraktů -Před psaním jednotkových testů je dobré vědět, jaké funkce chytrý kontrakt nabízí a jak k nim budou uživatelé přistupovat a používat je. To je užitečné zejména při provádění testů [šťastné cesty](https://en.m.wikipedia.org/wiki/Happy_path), které zjišťují, zda funkce v kontraktu vracejí správný výstup pro platné uživatelské vstupy. Tento koncept si vysvětlíme na tomto (zkráceném) příkladu [aukčního kontraktu.](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) +Před psaním jednotkových testů je dobré vědět, jaké funkce chytrý kontrakt nabízí a jak k nim budou uživatelé přistupovat a používat je. To je užitečné zejména při provádění [testů úspěšného průběhu](https://en.m.wikipedia.org/wiki/Happy_path), které zjišťují, zda funkce v kontraktu vracejí správný výstup pro platné uživatelské vstupy. Tento koncept vysvětlíme na tomto (zkráceném) příkladu [aukčního kontraktu](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) -``` +```solidity constructor( uint biddingTime, address payable beneficiaryAddress @@ -108,11 +108,11 @@ function auctionEnd() external { } ``` -Toto je jednoduchý aukční kontrakt určený k přijímání nabídek během přihazovacího období. Pokud se `highestBid` zvýší, předchozí účastník s nejvyšší nabídkou obdrží své peníze; jakmile přihazovací období skončí, `beneficiary` vypoví smlouvu a obdrží své peníze. +Toto je jednoduchý aukční kontrakt určený k přijímání nabídek během přihazovacího období. Pokud se `highestBid` zvýší, předchozí nejvyšší přihazující obdrží zpět své peníze; jakmile nabídkové období skončí, `beneficiary` (příjemce) zavolá kontrakt, aby získal své peníze. Jednotkové testy pro takový kontrakt by se týkaly různých funkcí, které by uživatel mohl volat při interakci s kontraktem. Příkladem může být jednotkový test, který kontroluje, zda uživatel může zadat nabídku, zatímco aukce probíhá (tj. volání `bid()` je úspěšné), nebo test, který kontroluje, zda uživatel může zadat vyšší nabídku, než je aktuální `highestBid`. -Pochopení provozního pracovního postupu kontraktu také pomáhá při psaní jednotkových testů, které kontrolují, zda provádění splňuje požadavky. Například aukční kontrakt určuje, že uživatelé nemohou podávat nabídky poté, co aukce skončí (tj. když `auctionEndTime` je nižší než `block.timestamp`). Vývojář tak může spustit jednotkový test, který kontroluje, zda volání funkce `bid()` uspěje nebo selže, když aukce skončí (tj. když `auctionEndTime` > `block.timestamp`). +Pochopení provozního pracovního postupu kontraktu také pomáhá při psaní jednotkových testů, které kontrolují, zda provádění splňuje požadavky. Například aukční kontrakt určuje, že uživatelé nemohou podávat nabídky, když aukce skončila (tj. když je `auctionEndTime` menší než `block.timestamp`). Vývojář tak může spustit jednotkový test, který kontroluje, zda volání funkce `bid()` uspěje nebo selže, když aukce skončila (tj. když `auctionEndTime` > `block.timestamp`). ##### 2. Vyhodnoďte všechny předpoklady související se spuštěním kontraktu @@ -126,11 +126,11 @@ Mnoho frameworků pro jednotkové testy umožňuje vytvářet tvrzení – jedno - Uživatelům, kteří aukci nevyhráli, jsou připsány jejich finanční prostředky. -**Poznámka**: Další možností testování předpokladů je psaní testů, které spouštějí [modifikátory funkcí](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) v kontraktu, zejména příkazy `require`, `assert` a `if…else`. +**Poznámka**: Dalším způsobem testování předpokladů je psaní testů, které spouštějí [modifikátory funkcí](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) v kontraktu, zejména příkazy `require`, `assert` a `if…else`. ##### 3. Změřte pokrytí kódu -[Pokrytí kódu](https://en.m.wikipedia.org/wiki/Code_coverage) je metrika testování, která sleduje počet větví, řádků a příkazů v kódu provedených během testů. Testy by měly mít dobré pokrytí kódu, aby se minimalizovalo riziko netestovaných zranitelností. Bez dostatečného pokrytí se můžete mylně domnívat, že váš kontrakt je bezpečný, protože všechny testy prošly, zatímco v netestovaných cestách kódu stále existují zranitelnosti. Zaznamenání vysokého pokrytí kódu však dává jistotu, že všechny příkazy/funkce v chytrém kontraktu byly dostatečně otestovány z hlediska správnosti. +[Pokrytí kódu](https://en.m.wikipedia.org/wiki/Code_coverage) je metrika testování, která sleduje počet větví, řádků a příkazů ve vašem kódu, které se provedou během testů. Testy by měly mít dobré pokrytí kódu, aby se minimalizovalo riziko netestovaných zranitelností. Bez dostatečného pokrytí se můžete mylně domnívat, že váš kontrakt je bezpečný, protože všechny testy prošly, zatímco v netestovaných cestách kódu stále existují zranitelnosti. Zaznamenání vysokého pokrytí kódu však dává jistotu, že všechny příkazy/funkce v chytrém kontraktu byly dostatečně otestovány z hlediska správnosti. ##### 4. Použijte dobře vyvinuté testovací frameworky @@ -138,19 +138,19 @@ Kvalita nástrojů používaných při spouštění jednotkových testů pro va Frameworky jednotkového testování pro chytré kontrakty Solidity existují v různých jazycích (většinou JavaScript, Python a Rust). Informace o tom, jak začít spouštět jednotkové testy s různými testovacími frameworky, najdete v některých z níže uvedených návodů: -- **[Spouštění jednotkových testů pomocí Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** -- **[Spouštění jednotkových testů pomocí Foundry](https://book.getfoundry.sh/forge/writing-tests)** -- **[Spouštění jednotkových testů pomocí Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** -- **[Spouštění jednotkových testů pomocí Remix](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** -- **[Spouštění jednotkových testů pomocí Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html)** -- **[Spouštění jednotkových testů pomocí Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** -- **[Spouštění jednotkových testů pomocí Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** +- **[Spouštění jednotkových testů s Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[Spouštění jednotkových testů s Foundry](https://book.getfoundry.sh/forge/writing-tests)** +- **[Spouštění jednotkových testů s Waffle](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[Spouštění jednotkových testů s Remixem](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[Spouštění jednotkových testů s Ape](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[Spouštění jednotkových testů s Hardhat](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[Spouštění jednotkových testů s Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** ### Integrační testování {#integration-testing-for-smart-contracts} -Zatímco jednotkové testy ladí funkce kontraktu izolovaně, integrační testy hodnotí součásti chytrého kontraktu jako celek. Integrační testování může odhalit problémy vyplývající z volání napříč kontrakty nebo interakcí mezi různými funkcemi ve stejném chytrém kontraktu. Integrační testy mohou například pomoci zkontrolovat, zda věci jako [dědičnost](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) a injekce závislostí fungují správně. +Zatímco jednotkové testy ladí funkce kontraktu izolovaně, integrační testy hodnotí součásti chytrého kontraktu jako celek. Integrační testování může odhalit problémy vyplývající z volání napříč kontrakty nebo interakcí mezi různými funkcemi ve stejném chytrém kontraktu. Integrační testy mohou například pomoci zkontrolovat, zda prvky jako [dědičnost](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) a vkládání závislostí (dependency injection) fungují správně. -Integrační testování je užitečné, pokud váš kontrakt používá modulární architekturu nebo se během provádění propojuje s jinými kontrakty na blockchainu. Jedním ze způsobů provádění integračních testů je [rozvětvit blockchain](/glossary/#fork) v určité míře (pomocí nástroje jako [Forge](https://book.getfoundry.sh/forge/fork-testing) nebo [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks) a simulovat interakce mezi vaším kontraktem a nasazenými kontrakty. +Integrační testování je užitečné, pokud váš kontrakt používá modulární architekturu nebo se během provádění propojuje s jinými kontrakty na blockchainu. Jedním ze způsobů provádění integračních testů je [vytvořit větev blockchainu](/glossary/#fork) v určité výšce (pomocí nástroje jako [Forge](https://book.getfoundry.sh/forge/fork-testing) nebo [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks)) a simulovat interakce mezi vaším kontraktem a nasazenými kontrakty. Rozvětvený blockchain se bude chovat podobně jako hlavní síť a bude mít účty s přidruženými stavy a zůstatky. Funguje však pouze jako lokální sandboxové vývojové prostředí, což znamená, že například pro transakce nebudete potřebovat skutečné ETH a vaše změny neovlivní skutečný protokol Etherea. @@ -158,46 +158,46 @@ Rozvětvený blockchain se bude chovat podobně jako hlavní síť a bude mít Testování na základě vlastností je proces kontroly, zda chytrý kontrakt splňuje nějakou definovanou vlastnost. Vlastnosti potvrzují skutečnosti o chování kontraktu, které by měly zůstat pravdivé v různých situacích – příkladem vlastnosti chytrého kontraktu může být „Aritmetické operace v kontraktu nikdy nepřetékají ani nepodtékají.“ -**Statická analýza** a **dynamická analýza** jsou dvě běžné techniky pro provádění testování na základě vlastností a obě mohou ověřit, zda kód programu (v tomto případě chytrého kontraktu) splňuje nějakou předem definovanou vlastnost. Některé nástroje pro testování na základě vlastností obsahují předdefinovaná pravidla o očekávaných vlastnostech kontraktu a kontrolují kód podle těchto pravidel, zatímco jiné umožňují vytvořit vlastní vlastnosti chytrého kontraktu. +**Statická analýza** a **dynamická analýza** jsou dvě běžné techniky pro provádění testování na základě vlastností a obě mohou ověřit, že kód programu (v tomto případě chytrého kontraktu) splňuje nějakou předem definovanou vlastnost. Některé nástroje pro testování na základě vlastností obsahují předdefinovaná pravidla o očekávaných vlastnostech kontraktu a kontrolují kód podle těchto pravidel, zatímco jiné umožňují vytvořit vlastní vlastnosti chytrého kontraktu. #### Statická analýza {#static-analysis} Statický analyzátor přijímá jako vstup zdrojový kód chytrého kontraktu a na výstupu deklaruje, zda kontrakt splňuje danou vlastnost, či nikoli. Na rozdíl od dynamické analýzy statická analýza nezahrnuje spuštění kontraktu a jeho analýzu z hlediska správnosti. Statická analýza namísto toho uvažuje o všech možných cestách, kterými by se chytrý kontrakt mohl během provádění vydat (tj. zkoumá strukturu zdrojového kódu a zjišťuje, co by to znamenalo pro fungování kontraktu za běhu). -[Lintování](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) a [statické testování](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) jsou běžné metody pro provádění statické analýzy kontraktů. Obě vyžadují analýzu nízkoúrovňových reprezentací provádění kontraktu, jako jsou [abstraktní syntaktické stromy](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) a [grafy toku řízení](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/), které vypisuje kompilátor. +[Linting](https://www.perforce.com/blog/qac/what-is-linting) a [statické testování](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) jsou běžné metody pro provádění statické analýzy kontraktů. Obě vyžadují analýzu nízkoúrovňových reprezentací provádění kontraktu, jako jsou [abstraktní syntaktické stromy](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) a [grafy řízení toku](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/), které jsou výstupem kompilátoru. Ve většině případů je statická analýza užitečná pro odhalení bezpečnostních problémů, jako je použití nebezpečných konstrukcí, syntaktických chyb nebo porušení kódovacích standardů v kódu kontraktu. Je však známo, že statické analyzátory nejsou obecně spolehlivé při odhalování hlubších zranitelností a mohou produkovat nadměrné množství falešně pozitivních výsledků. #### Dynamická analýza {#dynamic-analysis} -Dynamická analýza generuje symbolické vstupy (např. v [symbolickém provedení](https://en.m.wikipedia.org/wiki/Symbolic_execution)) nebo konkrétní vstupy (např. ve [fuzzingu](https://owasp.org/www-community/Fuzzing)) do funkcí chytrých kontraktů, aby zjistila, zda některá(é) stopa(y) provedení porušuje(í) konkrétní vlastnosti. Tato forma testování na základě vlastností se od jednotkových testů liší tím, že testovací případy pokrývají více situací a generování testovacích případů zajišťuje program. +Dynamická analýza generuje symbolické vstupy (např. v [symbolickém provádění](https://en.m.wikipedia.org/wiki/Symbolic_execution)) nebo konkrétní vstupy (např. ve [fuzzingu](https://owasp.org/www-community/Fuzzing)) do funkcí chytrých kontraktů, aby se zjistilo, zda některá ze stop provádění neporušuje specifické vlastnosti. Tato forma testování na základě vlastností se od jednotkových testů liší tím, že testovací případy pokrývají více situací a generování testovacích případů zajišťuje program. -[Fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) je příkladem techniky dynamické analýzy pro ověřování libovolných vlastností chytrých kontraktů. Fuzzer vyvolává funkce v cílovém kontraktu s náhodnými nebo chybnými variantami definované vstupní hodnoty. Pokud se chytrý kontrakt dostane do chybového stavu (např. do stavu, kdy selže tvrzení), je problém označen a v hlášení jsou uvedeny vstupy, které vedou provádění ke zranitelné cestě. +[Fuzzing](https://www.halborn.com/blog/post/what-is-fuzz-testing-fuzzing) je příkladem techniky dynamické analýzy pro ověřování libovolných vlastností v chytrých kontraktech. Fuzzer vyvolává funkce v cílovém kontraktu s náhodnými nebo chybnými variantami definované vstupní hodnoty. Pokud se chytrý kontrakt dostane do chybového stavu (např. do stavu, kdy selže tvrzení), je problém označen a v hlášení jsou uvedeny vstupy, které vedou provádění ke zranitelné cestě. Fuzzing je užitečný pro vyhodnocení mechanismu ověřování vstupů chytrých kontraktů, protože nesprávné zpracování neočekávaných vstupů může vést k nechtěnému spuštění a nebezpečným účinkům. Tato forma testování na základě vlastností může být ideální z mnoha důvodů: -1. **Psaní testovacích případů, které by pokryly mnoho situací, je obtížné.** Testování vlastností vyžaduje pouze definování chování a rozsahu dat, se kterými se chování testuje – program automaticky generuje testovací případy na základě definované vlastnosti. +1. **Psaní testovacích případů, které by pokryly mnoho scénářů, je obtížné.** Test založený na vlastnostech vyžaduje pouze to, abyste definovali chování a rozsah dat, s nimiž se má chování testovat – program automaticky generuje testovací případy na základě definované vlastnosti. -2. **Vaše sada testů nemusí dostatečně pokrývat všechny možné cesty v rámci programu.** I při 100% pokrytí je možné vynechat krajní případy. +2. **Vaše sada testů nemusí dostatečně pokrývat všechny možné cesty v rámci programu.** I při 100% pokrytí je možné vynechat okrajové případy. -3. **Jednotkové testy prokazují správné provedení kontraktu pro vzorová data, ale není známo, zda se kontrakt správně provede pro vstupy mimo vzorek.** Testy vlastností provádějí cílový kontrakt s více variantami dané vstupní hodnoty a hledají stopy provedení, které způsobují selhání tvrzení. Test vlastností tak poskytuje více záruk, že se kontrakt provede správně pro širokou třídu vstupních dat. +3. **Jednotkové testy prokazují, že se kontrakt provede správně pro vzorová data, ale zůstává neznámé, zda se provede správně pro vstupy mimo vzorek.** Testy založené na vlastnostech provádějí cílový kontrakt s více variantami dané vstupní hodnoty, aby našly stopy provádění, které způsobují selhání tvrzení. Test vlastností tak poskytuje více záruk, že se kontrakt provede správně pro širokou třídu vstupních dat. -### Pokyny pro testování chytrých kontraktů na základě vlastností {#running-property-based-tests} +### Pokyny pro provádění testování na základě vlastností pro chytré kontrakty {#running-property-based-tests} -Provádění testování na základě vlastností obvykle začíná definováním vlastnosti (např. nepřítomnost přetečení [celých čísel](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) nebo kolekce vlastností, které chcete v chytrém kontraktu ověřit. Při psaní testů vlastností může být také nutné definovat rozsah hodnot, ve kterém může program generovat data pro vstupy transakcí. +Provádění testování založeného na vlastnostech obvykle začíná definováním vlastnosti (např. absence [celočíselného přetečení](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow)) nebo souboru vlastností, které chcete v chytrém kontraktu ověřit. Při psaní testů vlastností může být také nutné definovat rozsah hodnot, ve kterém může program generovat data pro vstupy transakcí. Po správné konfiguraci bude nástroj pro testování vlastností vykonávat funkce vašich chytrých kontraktů s náhodně vygenerovanými vstupy. Pokud dojde k porušení tvrzení, měla by se zobrazit zpráva s konkrétními vstupními daty, která porušují vyhodnocovanou vlastnost. Podívejte se na některé z níže uvedených návodů, které vám pomohou začít s testováním na základě vlastností pomocí různých nástrojů: -- **[Statická analýza chytrých kontraktů pomocí Slither](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)** +- **[Statická analýza chytrých kontraktů pomocí Slither](https://github.com/crytic/slither)** - **[Statická analýza chytrých kontraktů pomocí Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** -- **[Testování na základě vlastností pomocí Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** -- **[Fuzzingové kontrakty s Foundry](https://book.getfoundry.sh/forge/fuzz-testing)** -- **[Fuzzingové kontrakty s Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** -- **[Fuzzingové kontrakty s Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** -- **[Symbolické provádění chytrých kontraktů pomocí Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** -- **[Symbolické provádění chytrých kontraktů pomocí Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** +- **[Testování na základě vlastností s Brownie](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[Fuzzing kontraktů s Foundry](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[Fuzzing kontraktů s Echidna](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[Fuzzing kontraktů s Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** +- **[Symbolické provádění chytrých kontraktů s Manticore](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** +- **[Symbolické provádění chytrých kontraktů s Mythril](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** -## Ruční testování pro chytré kontrakty {#manual-testing-for-smart-contracts} +## Ruční testování chytrých kontraktů {#manual-testing-for-smart-contracts} Ruční testování chytrých kontraktů často přichází na řadu později ve vývojovém cyklu po spuštění automatických testů. Tato forma testování hodnotí chytrý kontrakt jako jeden plně integrovaný produkt a zjišťuje, zda funguje tak, jak je uvedeno v technických požadavcích. @@ -205,104 +205,106 @@ Ruční testování chytrých kontraktů často přichází na řadu později ve Přestože automatizované testování prováděné v lokálním vývojovém prostředí může poskytnout užitečné informace pro ladění, budete chtít vědět, jak se váš chytrý kontrakt chová v produkčním prostředí. Nasazení do hlavního řetězce Etherea je však spojeno s poplatky za palivo – nemluvě o tom, že vy nebo vaši uživatelé můžete přijít o skutečné peníze, pokud má váš chytrý kontrakt stále chyby. -Testování kontraktu na lokálním blockchainu (známém také jako [vývojová síť](/developers/docs/development-networks/)) je doporučenou alternativou k testování na hlavní síti. Lokální blockchain je kopie blockchainu Etherea spuštěná lokálně na vašem počítači, která simuluje chování exekuční vrstvy Etherea. Proto můžete naprogramovat transakce pro interakci s kontraktem, aniž byste museli vynaložit značné režijní náklady. +Testování vašeho kontraktu na lokálním blockchainu (známém také jako [vývojová síť](/developers/docs/development-networks/)) je doporučenou alternativou k testování na hlavní síti. Lokální blockchain je kopie blockchainu Etherea spuštěná lokálně na vašem počítači, která simuluje chování exekuční vrstvy Etherea. Proto můžete naprogramovat transakce pro interakci s kontraktem, aniž byste museli vynaložit značné režijní náklady. -Spuštění kontraktů na lokálním blockchainu by mohlo být užitečné jako forma ručního integračního testování. [Chytré kontrakty jsou vysoce modulární](/developers/docs/smart-contracts/composability/), což umožňuje integraci se stávajícími protokoly, ale stále je třeba zajistit, aby tyto složité interakce na blockchainu vedly ke správným výsledkům. +Spuštění kontraktů na lokálním blockchainu by mohlo být užitečné jako forma ručního integračního testování. [Chytré kontrakty jsou vysoce skládatelné](/developers/docs/smart-contracts/composability/), což vám umožňuje integraci se stávajícími protokoly – stále ale budete muset zajistit, že takové složité interakce na blockchainu přinesou správné výsledky. -[Další informace o vývojových sítích.](/developers/docs/development-networks/) +[Více o vývojových sítích.](/developers/docs/development-networks/) -### Testování kontraktů v testovacích sítích {#testing-contracts-on-testnets} +### Testování kontraktů na testnetech {#testing-contracts-on-testnets} -Testovací síť neboli testnet funguje přesně jako hlavní síť Ethereum s tím rozdílem, že používá ether (ETH) bez reálné hodnoty. Nasazení kontraktu na [testovací síti](/developers/docs/networks/#ethereum-testnets) znamená, že s ním může kdokoli interagovat (např. prostřednictvím frontendu dappky), aniž by ohrozil finanční prostředky. +Testovací síť neboli testnet funguje přesně jako hlavní síť Ethereum s tím rozdílem, že používá ether (ETH) bez reálné hodnoty. Nasazení vašeho kontraktu na [testnet](/developers/docs/networks/#ethereum-testnets) znamená, že s ním může kdokoli interagovat (např. prostřednictvím frontendu dapps), aniž by riskoval finanční prostředky. Tato forma ručního testování je užitečná pro vyhodnocení komplexního toku aplikace z pohledu uživatele. Zde mohou beta testeři také provádět zkušební provoz a hlásit případné problémy s obchodní logikou a celkovou funkčností kontraktu. Nasazení v testovací síti po testování na lokálním blockchainu je ideální, protože první z nich je blíže chování virtuálního stroje Etherea. Proto je u mnoha projektů založených na Ethereu běžné nasazovat dappky v testovacích sítích, aby bylo možné vyhodnotit fungování chytrých kontraktů v reálných podmínkách. -[Další informace o testovacích sítích na Ethereu.](/developers/docs/development-networks/#public-beacon-testchains) +[Více o testnetech Etherea.](/developers/docs/development-networks/#public-beacon-testchains) ## Testování vs. formální ověřování {#testing-vs-formal-verification} -Testování sice pomáhá potvrdit, že kontrakt vrací očekávané výsledky pro některé datové vstupy, ale nemůže jednoznačně prokázat totéž pro vstupy, které nebyly během testů použity. Testování chytrého kontraktu proto nemůže zaručit „funkční správnost“ (tj. nemůže ukázat, že se program chová tak, jak je požadováno pro _všechny_ sady vstupních hodnot). +Testování sice pomáhá potvrdit, že kontrakt vrací očekávané výsledky pro některé datové vstupy, ale nemůže jednoznačně prokázat totéž pro vstupy, které nebyly během testů použity. Testování chytrého kontraktu proto nemůže zaručit "funkční správnost" (tj. nemůže ukázat, že se program chová tak, jak je požadováno pro _všechny_ sady vstupních hodnot). Formální ověřování je přístup k posuzování správnosti softwaru pomocí kontroly, zda formální model programu odpovídá formální specifikaci. Formální model je abstraktní matematická reprezentace programu, zatímco formální specifikace definuje vlastnosti programu (tj. logická tvrzení o provádění programu). Protože vlastnosti jsou zapsány v matematických termínech, je možné ověřit, zda formální (matematický) model systému splňuje specifikaci pomocí logických pravidel odvozování. Proto se říká, že formální ověřovací nástroje vytvářejí „matematický důkaz“ správnosti systému. -Na rozdíl od testování lze formální ověřování použít k ověření, že provádění chytrých kontraktů splňuje formální specifikaci pro _všechny_ provádění (tj. že neobsahuje žádné chyby), aniž by bylo nutné provádět je se vzorovými daty. Nejenže se tím zkrátí čas strávený spouštěním desítek jednotkových testů, ale je to také účinnější při odhalování skrytých zranitelností. Formální ověřovací techniky se přitom pohybují v různém spektru v závislosti na obtížnosti jejich implementace a užitečnosti. +Na rozdíl od testování lze formální ověřování použít k ověření, že provádění chytrého kontraktu splňuje formální specifikaci pro _všechna_ provádění (tj. že nemá žádné chyby), aniž by bylo nutné jej provádět se vzorovými daty. Nejenže se tím zkrátí čas strávený spouštěním desítek jednotkových testů, ale je to také účinnější při odhalování skrytých zranitelností. Formální ověřovací techniky se přitom pohybují v různém spektru v závislosti na obtížnosti jejich implementace a užitečnosti. -[Další informace o formálním ověřování chytrých kontraktů.](/developers/docs/smart-contracts/formal-verification) +[Více o formálním ověřování chytrých kontraktů.](/developers/docs/smart-contracts/formal-verification) -## Testování vs. audity a odměny za vyřešení chyb {#testing-vs-audits-bug-bounties} +## Testování vs. audity a odměny za nalezení chyb {#testing-vs-audits-bug-bounties} Jak již bylo zmíněno, důsledné testování může jen zřídka zaručit, že kontrakt neobsahuje chyby; formální ověřovací přístupy mohou poskytnout silnější záruky správnosti, ale v současné době je obtížné je používat a jsou s nimi spojeny značné náklady. -Přesto můžete možnost odhalení zranitelností kontraktu ještě zvýšit tím, že si necháte provést nezávislou revizi kódu. [Audity chytrých kontraktů](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) a [odměny za vyřešení chyb](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) jsou dva způsoby, jak přimět ostatní, aby analyzovali vaše kontrakty. +Přesto můžete možnost odhalení zranitelností kontraktu ještě zvýšit tím, že si necháte provést nezávislou revizi kódu. [Audity chytrých kontraktů](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) a [odměny za nalezení chyb](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) (bug bounties) jsou dva způsoby, jak přimět ostatní, aby analyzovali vaše kontrakty. Audity provádějí auditoři, kteří mají zkušenosti s odhalováním bezpečnostních nedostatků a špatných vývojových postupů v chytrých kontraktech. Audit obvykle zahrnuje testování (a případně formální ověření) a ruční kontrolu celé kódové základny. -Naproti tomu program odměn za vyřešení chyby obvykle zahrnuje nabídku finanční odměny jednotlivci (běžně označovanému jako [whitehat hacker](https://en.wikipedia.org/wiki/White_hat_(computer_security))), který objeví zranitelnost v chytrém kontraktu a odhalí ji vývojářům. Odměny za vyřešení chyb jsou podobné auditům, protože zahrnují žádost ostatních, aby pomohli najít chyby v chytrých kontraktech. +Naopak, program odměn za nalezení chyb (bug bounty) obvykle zahrnuje nabídku finanční odměny jednotlivci (běžně označovanému jako [whitehat hacker](https://en.wikipedia.org/wiki/White_hat_\(computer_security\))), který objeví zranitelnost v chytrém kontraktu a oznámí ji vývojářům. Odměny za vyřešení chyb jsou podobné auditům, protože zahrnují žádost ostatních, aby pomohli najít chyby v chytrých kontraktech. Hlavní rozdíl spočívá v tom, že programy odměn za vyřešení chyb jsou otevřené širší komunitě vývojářů/hackerů a přitahují širokou skupinu etických hackerů a nezávislých bezpečnostních odborníků s jedinečnými dovednostmi a zkušenostmi. To může být výhoda oproti auditům chytrých kontraktů, které se spoléhají především na týmy, které mohou mít omezené nebo úzké odborné znalosti. -## Testovací nástroje a knihovny {#testing-tools-and-libraries} +## Nástroje a knihovny pro testování {#testing-tools-and-libraries} ### Nástroje pro jednotkové testování {#unit-testing-tools} - **[solidity-coverage](https://github.com/sc-forks/solidity-coverage)** – _Nástroj pro pokrytí kódu chytrých kontraktů napsaných v Solidity._ -- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** – _Framework pro pokročilý vývoj a testování chytrých kontraktů (založený na ethers.js)_. +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** – _Framework pro pokročilý vývoj a testování chytrých kontraktů (založený na ethers.js)._ -- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** – _Nástroj pro testování chytrých kontraktů Solidity. Pracuje pod pluginem „Solidity Unit Testing“ v prostředí Remix IDE, který se používá k psaní a spouštění testovacích případů pro kontrakt._ +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** - _Nástroj pro testování chytrých kontraktů v Solidity._ Pracuje pod pluginem „Solidity Unit Testing“ v prostředí Remix IDE, který se používá k psaní a spouštění testovacích případů pro kontrakt._ -- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** – _Knihovna pro testování chytrých kontraktů na Ethereu. Ujistěte se, že se vaše kontrakty chovají podle očekávání!_ +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** – _Knihovna tvrzení pro testování chytrých kontraktů na Ethereu._ Ujistěte se, že se vaše kontrakty chovají podle očekávání!_ -- **[Brownie unit testing framework](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** – _Brownie využívá Pytest, funkčně bohatý testovací framework, který umožňuje psát malé testy s minimem kódu, dobře se škáluje pro velké projekty a je vysoce rozšiřitelný._ +- **[Framework pro jednotkové testování Brownie](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** – _Brownie využívá Pytest, testovací framework s bohatými funkcemi, který vám umožní psát malé testy s minimálním kódem, dobře se škáluje pro velké projekty a je vysoce rozšiřitelný._ -- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** – _Foundry nabízí Forge, rychlý a flexibilní framework pro testování na Ethereu, který dokáže provádět jednoduché jednotkové testy, kontroly optimalizace paliva a fuzzing kontraktů._ +- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/crates/forge)** – _Foundry nabízí Forge, rychlý a flexibilní framework pro testování na Ethereu, který je schopen provádět jednoduché jednotkové testy, kontroly optimalizace paliva a fuzzing kontraktů._ - **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** – _Framework pro testování chytrých kontraktů založený na ethers.js, Mocha a Chai._ -- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** – _Vývojový a testovací framework pro chytré kontrakty v jazyce Python zaměřený na virtuální stroj Etherea._ +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** – _Vývojový a testovací framework založený na Pythonu pro chytré kontrakty cílící na Ethereum Virtual Machine (EVM)._ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** – _Python framework pro jednotkové testování a fuzzing se silnými možnostmi ladění a podporou testování napříč blockchainy, využívající pytest a Anvil pro co nejlepší uživatelský zážitek a výkon._ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** – _Framework založený na Pythonu pro jednotkové testování a fuzzing se silnými možnostmi ladění a podporou testování napříč řetězci, využívající pytest a Anvil pro nejlepší uživatelský zážitek a výkon._ ### Nástroje pro testování na základě vlastností {#property-based-testing-tools} #### Nástroje pro statickou analýzu {#static-analysis-tools} -- **[Slither](https://github.com/crytic/slither)** – _Statický analytický framework v Solidity založený na Pythonu pro vyhledávání zranitelností, zlepšování srozumitelnosti kódu a psaní vlastních analýz pro chytré kontrakty._ +- **[Slither](https://github.com/crytic/slither)** – _Framework pro statickou analýzu Solidity založený na Pythonu pro hledání zranitelností, zlepšení srozumitelnosti kódu a psaní vlastních analýz pro chytré kontrakty._ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** – _Linter pro vynucování stylu a osvědčených postupů zabezpečení pro programovací jazyk chytrých kontraktů Solidity._ -- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** – _Linter pro vynucení nejlepších postupů stylu a zabezpečení pro programovací jazyk chytrých kontraktů Solidity._ +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** – _Statický analyzátor založený na Rustu speciálně navržený pro zabezpečení a vývoj chytrých kontraktů Web3._ -- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** – _Statický analyzátor založený na Rust speciálně navržený pro zabezpečení a vývoj chytrých kontraktů na Web3._ +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** – _Framework pro statickou analýzu založený na Pythonu s detektory zranitelností a kvality kódu, tiskárnami pro extrahování užitečných informací z kódu a podporou pro psaní vlastních submodulů._ -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** – _Statický analytický framework založený na Pythonu s detektory zranitelností a kvality kódu, nástroji pro extrakci užitečných informací z kódu a podporou psaní vlastních podmodulů._ +- **[Slippy](https://github.com/fvictorio/slippy)** – _Jednoduchý a výkonný linter pro Solidity._ #### Nástroje pro dynamickou analýzu {#dynamic-analysis-tools} -- **[Echidna](https://github.com/crytic/echidna/)** – _Rychlý fuzzer kontraktů pro odhalování zranitelností v chytrých kontraktech pomocí testování na základě vlastností._ +- **[Echidna](https://github.com/crytic/echidna/)** – _Rychlý fuzzer kontraktů pro detekci zranitelností v chytrých kontraktech pomocí testování založeného na vlastnostech._ -- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** – _Automatický fuzzing nástroj užitečný pro odhalování porušení vlastností v kódu chytrých kontraktů._ +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** – _Automatizovaný nástroj pro fuzzing užitečný pro detekci porušení vlastností v kódu chytrého kontraktu._ -- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** – _Dynamický framework pro symbolické spouštění pro analýzu EVM bytekódu._ +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** – _Dynamický framework pro symbolické provádění pro analýzu bytekódu EVM._ -- **[Mythril](https://github.com/ConsenSys/mythril-classic)** – _Nástroj pro vyhodnocování EVM bytekódu pro detekci zranitelností kontraktů pomocí analýzy taintů, analýzy concolic a kontroly toku řízení._ +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** – _Nástroj pro hodnocení bytekódu EVM pro detekci zranitelností kontraktů pomocí taint analýzy, konkolické analýzy a kontroly toku řízení._ -- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** – _Scribble je specifikační jazyk a runtime ověřovací nástroj, který umožňuje anotovat chytré kontrakty pomocí vlastností, které umožňují automatické testování kontraktů pomocí nástrojů, jako je Diligence Fuzzing nebo MythX._ +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** – _Scribble je specifikační jazyk a runtime ověřovací nástroj, který umožňuje anotovat chytré kontrakty vlastnostmi, které umožňují automatické testování kontraktů pomocí nástrojů, jako je Diligence Fuzzing nebo MythX._ ## Související návody {#related-tutorials} - [Přehled a srovnání různých testovacích produktů](/developers/tutorials/guide-to-smart-contract-security-tools/) \_ - [Jak používat Echidnu k testování chytrých kontraktů](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) -- [Jak používat Manticore k vyhledávání chyb v chytrých kontraktech](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [Jak používat Slither k hledání chyb ve smart kontraktech](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [Jak vytvořit maketu smlouvy Solidity pro testování](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) +- [Jak používat Manticore k nalezení chyb v chytrých kontraktech](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [Jak používat Slither k nalezení chyb v chytrých kontraktech](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [Jak mockovat kontrakty v Solidity pro účely testování](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) - [Jak spouštět jednotkové testy v Solidity pomocí Foundry](https://www.rareskills.io/post/foundry-testing-solidity) -## Další informace {#further-reading} +## Další čtení {#further-reading} - [Podrobný průvodce testováním chytrých kontraktů na Ethereu](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) - [Jak testovat chytré kontrakty na Ethereu](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) - [Průvodce jednotkovým testováním pro vývojáře od MolochDAO](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) -- [Jak testovat chytré kontrakt jako borec](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) +- [Jak testovat chytré kontrakty jako rocková hvězda](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/cs/developers/docs/smart-contracts/upgrading/index.md index 8bb877f0fad..e816cc4f638 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/upgrading/index.md @@ -1,6 +1,6 @@ --- -title: Vylepšení chytrých kontraktů -description: Přehled vzorů vylepšení pro chytré kontrakty na Ethereu +title: "Vylepšení chytrých kontraktů" +description: "Přehled vzorů vylepšení pro chytré kontrakty na Ethereu" lang: cs --- @@ -12,7 +12,7 @@ Zvýšený výzkum v oblasti vylepšování chytrých kontraktů však vedl k za ## Předpoklady {#prerequisites} -Měli byste dobře rozumět [chytrým kontraktům](/developers/docs/smart-contracts/), [anatomii chytrých kontraktů](/developers/docs/smart-contracts/anatomy/) a [virtuálnímu stroji Etherea (EVM)](/developers/docs/evm/). Tato příručka také předpokládá, že čtenáři mají znalosti o programování chytrých kontraktů. +Měli byste dobře rozumět [chytrým kontraktům](/developers/docs/smart-contracts/), [anatomii chytrých kontraktů](/developers/docs/smart-contracts/anatomy/) a [Virtuálnímu stroji Etherea (EVM)](/developers/docs/evm/). Tato příručka také předpokládá, že čtenáři mají znalosti o programování chytrých kontraktů. ## Co je to vylepšení chytrého kontraktu? {#what-is-a-smart-contract-upgrade} @@ -42,7 +42,7 @@ Posledním krokem při migraci kontraktu je přesvědčit uživatele, aby přeš Migrace kontraktu je relativně jednoduché a bezpečné opatření pro aktualizaci chytrých kontraktů bez narušení uživatelských interakcí. Ruční migrace uživatelských úložišť a zůstatků do nového kontraktu je však časově náročná a může být spojena s vysokými náklady na palivo. -[Více o migraci kontraktu.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) +[Více o migraci kontraktů.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) ### Mechanismus vylepšení č. 2: Oddělení dat {#data-separation} @@ -76,7 +76,7 @@ Z [dokumentace Solidity](https://docs.soliditylang.org/en/latest/introduction-to > _Existuje speciální varianta volání zprávy s názvem **delegatecall**, která je totožná s voláním zprávy až na to, že kód na cílové adrese se provádí v kontextu (tj. na adrese) volajícího kontraktu a `msg.sender` a `msg.value` nemění své hodnoty._ _To znamená, že kontrakt může za běhu dynamicky načíst kód z jiné adresy. Úložiště, aktuální adresa a zůstatek se stále vztahují k volajícímu kontraktu, pouze kód je převzat z volané adresy._ -Proxy kontrakt ví, že má zavolat `delegatecall`, kdykoli uživatel zavolá funkci, protože má v sobě zabudovanou funkci `fallback`. V programování Solidity se funkce [fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) provede, když volání funkce neodpovídá funkcím uvedeným v kontraktu. +Proxy kontrakt ví, že má zavolat `delegatecall`, kdykoli uživatel zavolá funkci, protože má v sobě zabudovanou funkci `fallback`. Při programování v Solidity se [funkce fallback](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) spouští, když volání funkce neodpovídá funkcím uvedeným v kontraktu. Zprovoznění proxy vzoru vyžaduje napsání vlastní nouzové funkce, která určuje, jak má proxy kontrakt zacházet s voláními funkcí, které nepodporuje. V tomto případě je záložní funkce proxy kontraktu naprogramována tak, aby iniciovala delegatecall a přesměrovala požadavek uživatele na aktuální implementaci logického kontraktu. @@ -84,7 +84,7 @@ Proxy kontrakt je ve výchozím nastavení neměnný, ale lze vytvářet nové l Ukázáním proxy kontraktu na nový logický kontrakt se změní kód prováděný při volání funkce proxy kontraktu uživateli. To nám umožňuje vylepšit logiku kontraktu, aniž bychom od uživatelů vyžadovali interakci s novým kontraktem. -Proxy vzory jsou oblíbenou metodou vylepšení chytrých kontraktů, protože eliminují obtíže spojené s migrací kontraktu. Použití proxy vzorů je však složitější a při nesprávném použití může způsobit kritické chyby, například [kolize selektorů funkcí](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357). +Proxy vzory jsou oblíbenou metodou vylepšení chytrých kontraktů, protože eliminují obtíže spojené s migrací kontraktu. Proxy vzory jsou však složitější na používání a při nesprávném použití mohou způsobit kritické chyby, jako jsou například [konflikty selektorů funkcí](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357). [Více o proxy vzorech](https://blog.openzeppelin.com/proxy-patterns/). @@ -100,11 +100,11 @@ Ačkoli je podobný dříve popsanému proxy vzoru, vzor strategie se liší, pr Hlavní nevýhodou je, že tento vzor je užitečný hlavně pro zavádění drobných vylepšení. Pokud je hlavní kontrakt kompromitován (např. hacknutím), nelze tento způsob vylepšení použít. -### Mechanismus aktualizace č. 5: Diamantový vzor {#diamond-pattern} +### Mechanismus vylepšení č. 5: Diamantový vzor {#diamond-pattern} Diamantový vzor lze považovat za vylepšení proxy vzoru. Diamantové vzory se od proxy vzorů liší tím, že diamantový proxy kontrakt může delegovat volání funkcí na více než jeden logický kontrakt. -Logické kontrakty v diamantovém vzoru se označují jako _fasety_. Aby diamantový vzor fungoval, je třeba v proxy kontraktu vytvořit mapování, které mapuje [selektory funkcí](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) na různé adresy faset. +Logické kontrakty v diamantovém vzoru jsou známé jako _fasety_. Aby diamantový vzor fungoval, je třeba v proxy kontraktu vytvořit mapování, které mapuje [selektory funkcí](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) na různé adresy faset. Když uživatel zavolá funkci, proxy kontrakt zkontroluje mapování a najde aspekt odpovědný za provedení dané funkce. Poté vyvolá `delegatecall` (pomocí funkce fallback) a přesměruje volání na příslušný logický kontrakt. @@ -118,23 +118,23 @@ Diamantový vzor vylepšení má oproti tradičním vzorům proxy vylepšení ur [Více o diamantovém vzoru](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w). -## Výhody a nevýhody vylepšení chytrých kontraktů {#pros-and-cons-of-upgrading-smart-contracts} +## Výhody a nevýhody vylepšování chytrých kontraktů {#pros-and-cons-of-upgrading-smart-contracts} -| Plusy | Mínusy | -| ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | +| Plusy | Minusy | +| ---------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Vylepšení chytrého kontraktu může usnadnit opravu zranitelností objevených ve fázi po nasazení. | Aktualizace chytrých kontraktů popírá myšlenku neměnnosti kódu, což má důsledky pro decentralizaci a bezpečnost. | | Vývojáři mohou pomocí vylepšení logiky přidávat do decentralizovaných aplikací nové funkce. | Uživatelé musí důvěřovat vývojářům, že nebudou svévolně upravovat chytré kontrakty. | | Vylepšení chytrých kontraktů mohou zvýšit bezpečnost koncových uživatelů, protože chyby lze rychle opravit. | Programování funkcí vylepšení do chytrých kontraktů přidává další vrstvu složitosti a zvyšuje možnost kritických chyb. | | Vylepšení kontraktů dávají vývojářům větší prostor pro experimentování s různými funkcemi a vylepšování dappek v průběhu času. | Možnost vylepšovat chytré kontrakty může vývojáře podnítit k rychlejšímu spuštění projektů, aniž by ve fázi vývoje provedli náležitou kontrolu. | -| | Nezabezpečené řízení přístupu nebo centralizace v chytrých kontraktech může škodlivým aktérům usnadnit provádění neoprávněných aktualizací. | +| | Nezabezpečené řízení přístupu nebo centralizace v chytrých kontraktech může škodlivým aktérům usnadnit provádění neoprávněných aktualizací. | -## Co vzít v úvahu při vylepšování chytrých kontraktů {#considerations-for-upgrading-smart-contracts} +## Co zvážit při vylepšování chytrých kontraktů {#considerations-for-upgrading-smart-contracts} 1. Používejte bezpečné mechanismy řízení přístupu/autorizace, abyste zabránili neoprávněným vylepšením chytrých kontraktů, zejména pokud používáte proxy vzory, vzory strategií nebo oddělení dat. Příkladem je omezení přístupu k funkci vylepšení tak, aby ji mohl volat pouze vlastník kontraktu. 2. Vylepšení chytrých kontraktů je složitá činnost a vyžaduje vysokou míru pečlivosti, aby se zabránilo zavedení zranitelností. -3. Snižte předpoklady důvěryhodnosti decentralizací procesu provádění vylepšení. Mezi možné strategie patří použití [kontraktu peněženky s více signatáři](/developers/docs/smart-contracts/#multisig) pro kontrolu vylepšení nebo požadavek, aby [členové DAO](/dao/) hlasovali o schválení vylepšení. +3. Snižte předpoklady důvěryhodnosti decentralizací procesu provádění vylepšení. Možné strategie zahrnují použití [kontraktu peněženky s více podpisy (multi-sig)](/developers/docs/smart-contracts/#multisig) pro kontrolu vylepšení nebo požadavek, aby [členové DAO](/dao/) hlasovali o schválení vylepšení. 4. Uvědomte si náklady spojené s vylepšením kontraktů. Například kopírování stavu (např. zůstatků uživatelů) ze starého kontraktu do nového během migrace kontraktu může vyžadovat více než jednu transakci, což znamená více poplatků za palivo. @@ -142,7 +142,7 @@ Diamantový vzor vylepšení má oproti tradičním vzorům proxy vylepšení ur Časové zámky dávají uživatelům určitý čas na opuštění systému, pokud nesouhlasí s navrhovanou změnou (např. vylepšením logiky nebo novými systémy poplatků). Bez časových zámků musí uživatelé důvěřovat vývojářům, že neimplementují libovolné změny v chytrém kontraktu bez předchozího upozornění. Nevýhodou je, že časové zámky omezují možnost rychle opravovat zranitelnosti. -## Zdroje {#resources} +## Zdroje informací {#resources} **OpenZeppelin Upgrades Plugins – _Sada nástrojů pro nasazení a zabezpečení vylepšitelných chytrých kontraktů._** @@ -151,15 +151,15 @@ Diamantový vzor vylepšení má oproti tradičním vzorům proxy vylepšení ur ## Návody {#tutorials} -- [Vylepšení vašich chytrých kontraktů | YouTube Tutoriál](https://www.youtube.com/watch?v=bdXJmWajZRY) od Patrick Collins -- [Tutoriál na migraci chytrého kontraktu na Ethereu](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) od Austin Griffith -- [Použití UUPS proxy vzoru k vylepšení chytrých kontraktů](https://blog.logrocket.com/author/praneshas/) od Pranesh A.S -- [Web3 Tutoriál: Napište vylepšitelný chytrý kontrakt (proxy) pomocí OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) od fangjun.eth +- [Vylepšování chytrých kontraktů | Tutoriál na YouTube](https://www.youtube.com/watch?v=bdXJmWajZRY) od Patricka Collinse +- [Tutoriál k migraci chytrých kontraktů na Ethereu](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) od Austina Griffitha +- [Použití proxy vzoru UUPS k vylepšení chytrých kontraktů](https://blog.logrocket.com/author/praneshas/) od Praneshe A.S +- [Web3 tutoriál: Jak napsat vylepšitelný chytrý kontrakt (proxy) pomocí OpenZeppelin](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) od fangjun.eth -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Stav vylepšení chytrých kontraktů](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) od Santiago Palladino -- [Více způsobů, jak vylepšit chytrý kontrakt Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) – Crypto Market Pool blog -- [Učení: Vylepšení chytrých kontraktů](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) – Dokumentace OpenZeppelin -- [Proxy vzory pro vylepšitelnost kontraktů Solidity: Transparentní vs. UUPS proxy](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) od Naveen Sahu -- [Jak fungují diamantová vylepšení](https://dev.to/mudgen/how-diamond-upgrades-work-417j) od Nick Mudge +- [Stav vylepšení chytrých kontraktů](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) od Santiaga Palladina +- [Několik způsobů, jak vylepšit chytrý kontrakt v Solidity](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) – blog Crypto Market Pool +- [Naučte se: Vylepšování chytrých kontraktů](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) – Dokumentace OpenZeppelin +- [Proxy vzory pro vylepšitelnost kontraktů v Solidity: Transparentní vs. UUPS proxy](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) od Naveena Sahu +- [Jak fungují diamantová vylepšení](https://dev.to/mudgen/how-diamond-upgrades-work-417j) od Nicka Mudge diff --git a/public/content/translations/cs/developers/docs/smart-contracts/verifying/index.md b/public/content/translations/cs/developers/docs/smart-contracts/verifying/index.md index 902e409e962..e4554cedc1d 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/verifying/index.md @@ -1,16 +1,16 @@ --- -title: Ověřování chytrých kontraktů -description: Přehled ověřování zdrojového kódu pro chytré kontrakty na Ethereu +title: "Ověřování chytrých kontraktů" +description: "Přehled ověřování zdrojového kódu pro chytré kontrakty na Ethereu" lang: cs --- [Chytré kontrakty](/developers/docs/smart-contracts/) jsou navrženy tak, aby byly „bez nutnosti další důvěry“, což znamená, že uživatelé by před interakcí s kontraktem neměli důvěřovat třetím stranám (např. vývojářům a společnostem). Podmínkou pro to je, aby uživatelé a další vývojáři mohli ověřit zdrojový kód chytrého kontraktu. Ověření zdrojového kódu zajišťuje uživatelům a vývojářům, že zveřejněný kód kontraktu je stejný kód, který běží na adrese kontraktu na blockchainu Etherea. -Je důležité rozlišovat mezi „ověřováním zdrojového kódu“ a „[formálním ověřováním](/developers/docs/smart-contracts/formal-verification/)“. Ověřování zdrojového kódu, které bude podrobně vysvětleno níže, se týká ověření, že se daný zdrojový kód chytrého kontraktu ve vysoce úrovňovém jazyce (např. Solidity) zkompiluje do stejného bytekódu, který má být spuštěn na adrese kontraktu. Formální ověřování však popisuje ověření správnosti chytrého kontraktu, což znamená, že se kontrakt chová podle očekávání. Ačkoli ověřování kontraktu závisí na kontextu, obvykle se vztahuje na ověření zdrojového kódu. +Je důležité rozlišovat mezi „ověřováním zdrojového kódu“ a „[formálním ověřováním](/developers/docs/smart-contracts/formal-verification/)“. Ověřování zdrojového kódu, které bude podrobně vysvětleno níže, se týká ověření, že se daný zdrojový kód chytrého kontraktu ve vysokoúrovňovém jazyce (např. Solidity) zkompiluje do stejného bytekódu, který má být spuštěn na adrese kontraktu. Formální ověřování však popisuje ověření správnosti chytrého kontraktu, což znamená, že se kontrakt chová podle očekávání. Ačkoli ověřování kontraktu závisí na kontextu, obvykle se vztahuje na ověření zdrojového kódu. ## Co je ověřování zdrojového kódu? {#what-is-source-code-verification} -Před nasazením chytrého kontraktu do [Virtuálního stroje Etherea (EVM)](/developers/docs/evm/) vývojáři [kompilují](/developers/docs/smart-contracts/compiling/) zdrojový kód kontraktu – instrukce [napsané v jazyce Solidity](/developers/docs/smart-contracts/languages/) nebo jiném vysokoúrovňovém programovacím jazyce – do bytekódu. Jelikož EVM nedokáže interpretovat vysokoúrovňové instrukce, je pro provádění logiky kontraktu v EVM nutná kompilace zdrojového kódu do bytekódu (tj. nízkoúrovňových strojových instrukcí). +Před nasazením chytrého kontraktu do [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) vývojáři [kompilují](/developers/docs/smart-contracts/compiling/) zdrojový kód kontraktu – instrukce [napsané v Solidity](/developers/docs/smart-contracts/languages/) nebo jiném vysokoúrovňovém programovacím jazyce – do bytekódu. Jelikož EVM nedokáže interpretovat vysokoúrovňové instrukce, je pro provádění logiky kontraktu v EVM nutná kompilace zdrojového kódu do bytekódu (tj. nízkoúrovňových strojových instrukcí). Ověřování zdrojového kódu je porovnávání zdrojového kódu chytrého kontraktu a zkompilovaného bytekódu použitého při vytváření kontraktu s cílem odhalit případné rozdíly. Ověřování chytrých kontraktů je důležité, protože inzerovaný kód kontraktu se může lišit od toho, který běží na blockchainu. @@ -20,17 +20,17 @@ Ověřování chytrých kontraktů umožňuje zkoumat, co kontrakt dělá, prost Některé části zdrojového kódu nemají na zkompilovaný bytekód vliv, například komentáře nebo názvy proměnných. To znamená, že dva zdrojové kódy s různými názvy proměnných a různými komentáři budou schopny ověřit stejný kontrakt. Záškodník tak může do zdrojového kódu přidat klamavé komentáře nebo uvést zavádějící názvy proměnných a nechat ověřit kontrakt s jiným zdrojovým kódem, než je původní zdrojový kód. -Tomu je možné se vyhnout tak, že se k bytekódu připojí další data, která slouží jako _kryptografická záruka_ přesnosti zdrojového kódu a jako _otisk prstu_ informací o kompilaci. Potřebné informace se nacházejí v [metadatech kontraktu Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html) a hash tohoto souboru je připojen k bytekódu kontraktu. Můžete si je prohlédnout v akci na [metadatovém hřišti](https://playground.sourcify.dev) +Tomu je možné se vyhnout tak, že se k bytekódu připojí další data, která slouží jako _kryptografická záruka_ přesnosti zdrojového kódu a jako _otisk prstu_ informací o kompilaci. Potřebné informace se nacházejí v [metadatech kontraktu Solidity](https://docs.soliditylang.org/en/v0.8.15/metadata.html) a haš tohoto souboru je připojen k bytekódu kontraktu. Můžete si to prohlédnout v akci v [metadata playgroundu](https://playground.sourcify.dev). Soubor metadat obsahuje informace o kompilaci kontraktu včetně zdrojových souborů a jejich hashů. To znamená, že pokud se změní nastavení kompilace nebo dokonce jediný bajt v některém ze zdrojových souborů, změní se i soubor metadat. V důsledku toho se změní i hash souboru metadat, který je připojen k bytekódu. To znamená, že pokud se bytekód kontraktu + připojený hash metadat shodují s daným zdrojovým kódem a nastavením kompilace, můžeme si být jisti, že se jedná o přesně stejný zdrojový kód, který byl použit při původní kompilaci, a že se neliší ani o jediný bajt. -Tento typ ověření, který využívá hash metadat, se označuje jako **„[úplné ověření](https://docs.sourcify.dev/docs/full-vs-partial-match/)“** (také „dokonalé ověření“). Pokud se hashe metadat neshodují nebo nejsou při ověřování brány v úvahu, jedná se o „částečnou shodu“, což je v současné době běžnější způsob ověřování kontraktů. Bez úplného ověření je možné [vložit škodlivý kód](https://samczsun.com/hiding-in-plain-sight/), který by se v ověřeném zdrojovém kódu neprojevil. Většina vývojářů si není vědoma úplného ověření a neuchovává soubor s metadaty o své kompilaci, proto je částečné ověření dosud de facto metodou ověřování kontraktů. +Tento typ ověření, který využívá haš metadat, se označuje jako **„[úplné ověření](https://docs.sourcify.dev/docs/full-vs-partial-match/)“** (také „dokonalé ověření“). Pokud se hashe metadat neshodují nebo nejsou při ověřování brány v úvahu, jedná se o „částečnou shodu“, což je v současné době běžnější způsob ověřování kontraktů. Je možné [vložit škodlivý kód](https://samczsun.com/hiding-in-plain-sight/), který by se v ověřeném zdrojovém kódu bez úplného ověření neprojevil. Většina vývojářů si není vědoma úplného ověření a neuchovává soubor s metadaty o své kompilaci, proto je částečné ověření dosud de facto metodou ověřování kontraktů. ## Proč je ověřování zdrojového kódu důležité? {#importance-of-source-code-verification} -### Bez nutnosti další důvěry {#trustlessness} +### Nevyžadování důvěry {#trustlessness} -Skutečnost, že není potřeba další důvěry je pravděpodobně největším předpokladem pro chytré kontrakty a [decentralizované aplikace (dappky)](/developers/docs/dapps/). Chytré kontrakty jsou „neměnné“ a nelze je pozměnit; kontrakt provede pouze obchodní logiku definovanou v kódu v době nasazení. To znamená, že vývojáři a podniky nemohou manipulovat s kódem kontraktu po jeho nasazení na Ethereu. +Nevyžadování důvěry je pravděpodobně největším předpokladem pro chytré kontrakty a [decentralizované aplikace (dapps)](/developers/docs/dapps/). Chytré kontrakty jsou „neměnné“ a nelze je pozměnit; kontrakt provede pouze obchodní logiku definovanou v kódu v době nasazení. To znamená, že vývojáři a podniky nemohou manipulovat s kódem kontraktu po jeho nasazení na Ethereu. Aby chytrý kontrakt fungoval bez nutnosti další důvěry, měl by být kód kontraktu dostupný pro nezávislé ověření. Zatímco zkompilovaný bytekód pro každý chytrý kontrakt je veřejně dostupný na blockchainu, nízkoúrovňový jazyk je obtížně srozumitelný jak pro vývojáře, tak pro uživatele. @@ -44,9 +44,9 @@ U chytrých kontraktů je obvykle v sázce spousta peněz. To vyžaduje vyšší Zveřejnění souborů se zdrojovým kódem chytrého kontraktu usnadňuje zájemcům, například auditorům, posouzení kontraktu z hlediska možných vektorů útoku. Díky tomu, že chytrý kontrakt nezávisle ověřuje více stran, mají uživatelé větší záruku jeho bezpečnosti. -## Jak ověřit zdrojový kód chytrých kontraktů na Ethereu {#source-code-verification-for-ethereum-smart-contracts} +## Jak ověřit zdrojový kód pro chytré kontrakty na Ethereu {#source-code-verification-for-ethereum-smart-contracts} -[Nasazení chytrého kontraktu na Ethereu](/developers/docs/smart-contracts/deploying/) vyžaduje odeslání transakce s datovým payloadem (zkompilovaným bytekódem) na speciální adresu. Datový payload je generován kompilací zdrojového kódu a [argumentů konstruktoru](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) instance kontraktu připojené k datovému payloadu v transakci. Kompilace je deterministická, což znamená, že při použití stejných zdrojových souborů a nastavení kompilace (např. verze překladače, optimalizátor) je vždy vytvořen stejný výstup (tj. bytekód kontraktu). +[Nasazení chytrého kontraktu na Ethereu](/developers/docs/smart-contracts/deploying/) vyžaduje odeslání transakce s datovým payloadem (zkompilovaným bytekódem) na speciální adresu. Datový payload je generován kompilací zdrojového kódu a [argumenty konstruktoru](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) instance kontraktu, připojené k datovému payloadu v transakci. Kompilace je deterministická, což znamená, že při použití stejných zdrojových souborů a nastavení kompilace (např. verze překladače, optimalizátor) je vždy vytvořen stejný výstup (tj. bytekód kontraktu). ![Diagram znázorňující ověření zdrojového kódu chytrého kontraktu](./source-code-verification.png) @@ -62,7 +62,7 @@ Ověření chytrého kontraktu v podstatě zahrnuje následující kroky: 5. Pokud se navíc hashe metadat na konci bytekódu shodují, jedná se o úplnou shodu. -Berte v úvahu, že se jedná o zjednodušený popis ověřování a existuje mnoho výjimek, které by v tomto případě nefungovaly, například [neměnné proměnné](https://docs.sourcify.dev/docs/immutables/). +Berte na vědomí, že se jedná o zjednodušený popis ověření a existuje mnoho výjimek, na které by se tento postup nevztahoval, například existence [neměnných proměnných](https://docs.sourcify.dev/docs/immutables/). ## Nástroje pro ověřování zdrojového kódu {#source-code-verification-tools} @@ -72,36 +72,42 @@ Tradiční proces ověřování kontraktů může být složitý. Proto máme n Ačkoli je Etherscan známý především jako [prohlížeč blockchainu Etherea](/developers/docs/data-and-analytics/block-explorers/), nabízí také [službu ověřování zdrojového kódu](https://etherscan.io/verifyContract) pro vývojáře a uživatele chytrých kontraktů. -Etherscan umožňuje překompilovat bytekód kontraktu z původního datového payloadu (zdrojový kód, adresa knihovny, nastavení kompilátoru, adresa kontraktu atd.). Pokud je překompilovaný bytekód spojen s bytekódem (a parametry konstruktoru) kontraktu na blockchainu, pak je [kontrakt ověřen](https://info.etherscan.com/types-of-contract-verification/). +Etherscan umožňuje překompilovat bytekód kontraktu z původního datového payloadu (zdrojový kód, adresa knihovny, nastavení kompilátoru, adresa kontraktu atd.). Pokud je znovu zkompilovaný bytekód spojen s bytekódem (a parametry konstruktoru) kontraktu na blockchainu, pak je [kontrakt ověřen](https://info.etherscan.com/types-of-contract-verification/). Po ověření obdrží zdrojový kód vašeho kontraktu označení „Ověřeno“ a je zveřejněn na Etherscanu, kde ho mohou kontrolovat ostatní. Přidá se také do sekce [Ověřené kontrakty](https://etherscan.io/contractsVerified/) – úložiště chytrých kontraktů s ověřenými zdrojovými kódy. -Etherscan je nejpoužívanějším nástrojem pro ověřování kontraktů. Ověřování kontraktu na Etherscanu má však nevýhodu: nedokáže porovnat **hash metadat** bytekódu na blockchainu a překompilovaného bytekódu. Shody v programu Etherscan jsou proto pouze částečné. +Etherscan je nejpoužívanějším nástrojem pro ověřování kontraktů. Ověřování kontraktů na Etherscanu má však nevýhodu: nedokáže porovnat **haš metadat** bytekódu na blockchainu a znovu zkompilovaného bytekódu. Shody v programu Etherscan jsou proto pouze částečné. -[ Více o ověřování kontraktů na Etherscanu](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). +[Více o ověřování kontraktů na Etherscanu](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). + +### Blockscout {#blockscout} + +[Blockscout](https://blockscout.com/) je open-source prohlížeč blockchainu, který také poskytuje [službu ověřování kontraktů](https://eth.blockscout.com/contract-verification) pro vývojáře a uživatele chytrých kontraktů. Jako open-source alternativa nabízí Blockscout transparentnost v tom, jak se ověřování provádí, a umožňuje komunitě přispívat ke zlepšení procesu ověřování. + +Podobně jako jiné ověřovací služby vám Blockscout umožňuje ověřit zdrojový kód vašeho kontraktu tak, že znovu zkompiluje bytekód a porovná jej s nasazeným kontraktem. Po ověření získá váš kontrakt stav ověření a zdrojový kód se stane veřejně dostupným pro audit a interakci. Ověřené kontrakty jsou také uvedeny v [úložišti ověřených kontraktů](https://eth.blockscout.com/verified-contracts) Blockscout pro snadné procházení a vyhledávání. ### Sourcify {#sourcify} -[Sourcify](https://sourcify.dev/#/verifier) je další nástroj pro ověřování kontraktů, který je open-source a decentralizovaný. Není to průzkumník bloků a ověřuje pouze kontrakty v [různých sítích založených na EVM](https://docs.sourcify.dev/docs/chains). Funguje jako veřejná infrastruktura pro další nástroje, které na ní mohou stavět, a jejím cílem je umožnit lidsky přívětivější interakce s kontrakty pomocí komentářů [ABI](/developers/docs/smart-contracts/compiling/#web-applications) a [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html), které se nacházejí v souboru metadat. +[Sourcify](https://sourcify.dev/#/verifier) je další open-source a decentralizovaný nástroj pro ověřování kontraktů. Není to prohlížeč bloků a ověřuje pouze kontrakty v [různých sítích založených na EVM](https://docs.sourcify.dev/docs/chains). Funguje jako veřejná infrastruktura pro další nástroje, které na ní mohou stavět, a jejím cílem je umožnit lidsky přívětivější interakce s kontrakty pomocí komentářů [ABI](/developers/docs/smart-contracts/compiling/#web-applications) a [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html), které se nacházejí v souboru metadat. -Na rozdíl od Etherscanu podporuje Sourcify úplné shody s hashem metadat. Ověřené kontrakty jsou doručovány do jeho [veřejného úložiště](https://docs.sourcify.dev/docs/repository/) na HTTP a [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), což je decentralizované, [obsahem adresované](https://web3.storage/docs/concepts/content-addressing/) úložiště. To umožňuje načtení souboru metadat kontraktu přes IPFS, protože připojený hash metadat je hash IPFS. +Na rozdíl od Etherscanu podporuje Sourcify úplné shody s hashem metadat. Ověřené kontrakty se poskytují v jeho [veřejném úložišti](https://docs.sourcify.dev/docs/repository/) přes HTTP a [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), což je decentralizované [úložiště s adresováním podle obsahu](https://docs.storacha.network/concepts/content-addressing/). To umožňuje načtení souboru metadat kontraktu přes IPFS, protože připojený hash metadat je hash IPFS. -Kromě toho lze přes IPFS načíst také soubory se zdrojovým kódem, protože v metadatech IPFS se nacházejí také hashe těchto souborů. Kontrakt lze ověřit poskytnutím souboru metadat a zdrojových souborů prostřednictvím rozhraní API nebo [UI](https://sourcify.dev/#/verifier) nebo pomocí pluginů. Monitorovací nástroj Sourcify také aktivně sleduje vytváření kontraktů na nových blocích a snaží se ověřit kontrakty, pokud jsou jejich metadata a zdrojové soubory zveřejněny na systému IPFS. +Kromě toho lze přes IPFS načíst také soubory se zdrojovým kódem, protože v metadatech IPFS se nacházejí také hashe těchto souborů. Kontrakt lze ověřit poskytnutím souboru metadat a zdrojových souborů prostřednictvím jeho API nebo [UI](https://sourcify.dev/#/verifier), nebo pomocí pluginů. Monitorovací nástroj Sourcify také aktivně sleduje vytváření kontraktů na nových blocích a snaží se ověřit kontrakty, pokud jsou jejich metadata a zdrojové soubory zveřejněny na systému IPFS. -[ Více informací o ověřování kontraktů na Sourcify](https://blog.soliditylang.org/2020/06/25/sourcify-faq/). +[Více o ověřování kontraktů na Sourcify](https://soliditylang.org/blog/2020/06/25/sourcify-faq/). ### Tenderly {#tenderly} -[Platforma Tenderly](https://tenderly.co/) umožňuje vývojářům Web3 vytvářet, testovat, monitorovat a provozovat chytré kontrakty. Tenderly kombinuje ladicí nástroje s pozorovatelností a stavebními bloky infrastruktury a pomáhá vývojářům urychlit vývoj chytrých kontraktů. Aby mohli vývojáři plně využívat funkce Tenderly, musí [provádět ověřování zdrojového kódu](https://docs.tenderly.co/monitoring/contract-verification) pomocí několika metod. +[Platforma Tenderly](https://tenderly.co/) umožňuje vývojářům Web3 vytvářet, testovat, monitorovat a provozovat chytré kontrakty. Tenderly kombinuje ladicí nástroje s pozorovatelností a stavebními bloky infrastruktury a pomáhá vývojářům urychlit vývoj chytrých kontraktů. Aby mohli vývojáři plně využívat funkce Tenderly, musí [provést ověření zdrojového kódu](https://docs.tenderly.co/monitoring/contract-verification) pomocí několika metod. Kontrakt je možné ověřit soukromě nebo veřejně. Pokud je chytrý kontrakt ověřen soukromě, je viditelný pouze pro vás (a ostatní členy vašeho projektu). Veřejné ověření kontraktu ho zviditelní všem uživatelům platformy Tenderly. -Vaše kontrakty můžete ověřit pomocí [Hlavního panelu](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), [pluginu Tenderly Hardhat](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) nebo [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli). +Své kontrakty můžete ověřit pomocí [Dashboardu](https://docs.tenderly.co/contract-verification), [pluginu Tenderly Hardhat](https://docs.tenderly.co/contract-verification/hardhat) nebo [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli). Při ověřování kontraktů prostřednictvím hlavního panelu je třeba importovat zdrojový soubor nebo soubor metadat vygenerovaný kompilátorem Solidity, adresu/síť a nastavení kompilátoru. Použití pluginu Tenderly Hardhat umožňuje větší kontrolu nad procesem ověřování s menším úsilím a umožňuje volit mezi automatickým (bez kódu) a ručním (na základě kódu) ověřováním. -## Další informace {#further-reading} +## Další čtení {#further-reading} - [Ověřování zdrojového kódu kontraktu](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/cs/developers/docs/standards/index.md b/public/content/translations/cs/developers/docs/standards/index.md new file mode 100644 index 00000000000..4dd4bc404a7 --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/index.md @@ -0,0 +1,59 @@ +--- +title: "Vývojové standardy Etherea" +description: "Seznamte se se standardy Etherea, včetně EIP, tokenových standardů jako ERC-20 a ERC-721 a vývojových konvencí." +lang: cs +incomplete: true +--- + +## Přehled standardů {#standards-overview} + +Komunita Etherea přijala mnoho standardů, které pomáhají udržovat projekty (jako jsou [klienti Etherea](/developers/docs/nodes-and-clients/) a peněženky) interoperabilní napříč implementacemi a zajišťují, že chytré kontrakty a dapps zůstávají skládatelné. + +Standardy jsou obvykle zaváděny jako [Návrhy na vylepšení Etherea (EIP)](/eips/), které jsou projednávány členy komunity prostřednictvím [standardního procesu](https://eips.ethereum.org/EIPS/eip-1). + +- [Úvod do EIP](/eips/) +- [Seznam EIP](https://eips.ethereum.org/) +- [GitHub repozitář EIP](https://github.com/ethereum/EIPs) +- [Diskusní fórum o EIP](https://ethereum-magicians.org/c/eips) +- [Úvod do správy Etherea](/governance/) +- [Přehled správy Etherea](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _31. března 2019 - Boris Mann_ +- [Správa vývoje protokolu Ethereum a koordinace upgradu sítě](https://hudsonjameson.com/posts/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _23. března 2020 - Hudson Jameson_ +- [Playlist všech schůzek vývojářů jádra Etherea](https://www.youtube.com/@EthereumProtocol) _(Playlist na YouTube)_ + +## Typy standardů {#types-of-standards} + +Existují 3 typy EIP: + +- Standardizační stopa: popisuje jakoukoli změnu, která ovlivňuje většinu nebo všechny implementace Etherea +- [Meta stopa](https://eips.ethereum.org/meta): popisuje proces týkající se Etherea nebo navrhuje změnu procesu +- [Informační stopa](https://eips.ethereum.org/informational): popisuje problém v návrhu Etherea nebo poskytuje obecné pokyny či informace komunitě Etherea + +Dále se standardizační stopa dělí do 4 kategorií: + +- [Jádro](https://eips.ethereum.org/core): vylepšení vyžadující větev konsensu +- [Síť](https://eips.ethereum.org/networking): vylepšení týkající se devp2p a Light Ethereum Subprotocol, jakož i navrhovaná vylepšení specifikací síťových protokolů Whisper a Swarm. +- [Rozhraní](https://eips.ethereum.org/interface): vylepšení specifikací a standardů klientského API/RPC a určitých standardů na úrovni jazyka, jako jsou názvy metod a ABI kontraktů. +- [ERC](https://eips.ethereum.org/erc): standardy a konvence na úrovni aplikace + +Podrobnější informace o těchto různých typech a kategoriích naleznete v [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) + +### Tokenové standardy {#token-standards} + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) – standardní rozhraní pro zaměnitelné (fungible) tokeny, jako jsou hlasovací tokeny, stakovací tokeny nebo virtuální měny. + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Standard zaměnitelných tokenů, díky kterému se tokeny chovají stejně jako ether a který podporuje zpracování přenosů tokenů na straně příjemce. + - [ERC-1363](/developers/docs/standards/tokens/erc-1363/) - Rozšiřující rozhraní pro tokeny ERC-20, které podporuje provádění zpětného volání (callback) na kontraktech příjemce v jediné transakci. +- [ERC-721](/developers/docs/standards/tokens/erc-721/) – standardní rozhraní pro nezaměnitelné tokeny, jako je listina k uměleckému dílu nebo písni. + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) - Standardizovaná událost emitovaná při vytváření/převodu jednoho nebo více nezaměnitelných tokenů s použitím po sobě jdoucích identifikátorů tokenů. + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) - Rozšíření rozhraní pro roli spotřebitele EIP-721. + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) - Přidává časově omezenou roli s omezenými oprávněními k tokenům ERC-721. +- [ERC-777](/developers/docs/standards/tokens/erc-777/) - **(NEDOPORUČUJE SE)** Tokenový standard, který vylepšuje ERC-20. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – tokenový standard, který může obsahovat jak zaměnitelná, tak nezaměnitelná aktiva. +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) - Standard pro tokenizované trezory navržený pro optimalizaci a sjednocení technických parametrů trezorů nesoucích výnos. + +Zjistěte více o [tokenových standardech](/developers/docs/standards/tokens/). + +## Další čtení {#further-reading} + +- [Návrhy na vylepšení Etherea (EIP)](/eips/) + +_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/standards/tokens/erc-1155/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-1155/index.md new file mode 100644 index 00000000000..67b748d6a4d --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-1155/index.md @@ -0,0 +1,146 @@ +--- +title: "Multitokenový standard ERC-1155" +description: "Seznamte se s ERC-1155, standardem pro více tokenů, který v jednom smart kontraktu kombinuje zastupitelné a nezastupitelné tokeny." +lang: cs +--- + +## Úvod {#introduction} + +Standardní rozhraní pro kontrakty, které spravují více typů tokenů. Jeden nasazený kontrakt může obsahovat libovolnou kombinaci zastupitelných tokenů, nezastupitelných tokenů nebo jiných konfigurací (např. polozastupitelných tokenů). + +**Co znamená multitokenový standard?** + +Myšlenka je jednoduchá a usiluje o vytvoření smart kontraktového rozhraní, které může reprezentovat a kontrolovat libovolný počet zaměnitelných a nezaměnitelných typů tokenů. Token ERC-1155 tak může plnit stejné funkce jako tokeny [ERC-20](/developers/docs/standards/tokens/erc-20/) a [ERC-721](/developers/docs/standards/tokens/erc-721/), a dokonce i obě najednou. Zlepšuje funkčnost standardů ERC-20 a ERC-721, činí je efektivnějšími a opravuje zjevné chyby v implementaci. + +Token ERC-1155 je plně popsán v [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155). + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky doporučujeme nejprve si přečíst o [standardech tokenů](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/) a [ERC-721](/developers/docs/standards/tokens/erc-721/). + +## Funkce a vlastnosti ERC-1155: {#body} + +- [Dávkový převod](#batch_transfers): Převod více aktiv v jednom volání. +- [Dávkový zůstatek](#batch_balance): Získání zůstatků více aktiv v jednom volání. +- [Dávkové schválení](#batch_approval): Schválení všech tokenů na adresu. +- [Háky](#receive_hook): Hák pro příjem tokenů. +- [Podpora NFT](#nft_support): Pokud je zásoba pouze 1, považuje se za NFT. +- [Pravidla pro bezpečný převod](#safe_transfer_rule): Sada pravidel pro bezpečný převod. + +### Dávkové převody {#batch-transfers} + +Hromadný přenos funguje velmi podobně jako běžné přenosy ERC-20. Podívejme se na běžnou funkci `transferFrom` v ERC-20: + +```solidity +// ERC-20 +function transferFrom(address from, address to, uint256 value) external returns (bool); + +// ERC-1155 +function safeBatchTransferFrom( + address _from, + address _to, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external; +``` + +Jediný rozdíl v ERC-1155 je ten, že předáváme hodnoty jako pole a také předáváme pole ID. Například pokud jsou `ids=[3, 6, 13]` a `values=[100, 200, 5]`, výsledné převody budou: + +1. Převod 100 tokenů s ID 3 z `_from` na `_to`. +2. Převod 200 tokenů s ID 6 z `_from` na `_to`. +3. Převod 5 tokenů s ID 13 z `_from` na `_to`. + +V ERC-1155 máme pouze `transferFrom`, žádný `transfer`. Chcete-li ji použít jako běžný `transfer`, stačí nastavit odesílající adresu na adresu, která funkci volá. + +### Dávkový zůstatek {#batch-balance} + +Odpovídající volání `balanceOf` v ERC-20 má také svou partnerskou funkci s podporou dávkového zpracování. Pro připomenutí, takto vypadá verze ERC-20: + +```solidity +// ERC-20 +function balanceOf(address owner) external view returns (uint256); + +// ERC-1155 +function balanceOfBatch( + address[] calldata _owners, + uint256[] calldata _ids +) external view returns (uint256[] memory); +``` + +Ještě jednodušší je volání za účelem získání informace o zůstatcích: V jednom volání můžeme získat několik zůstatků najednou. Předáváme pole vlastníků, následované polem ID tokenů. + +Například pokud jsou `_ids=[3, 6, 13]` a `_owners=[0xbeef..., 0x1337..., 0x1111...]`, návratová hodnota bude: + +```solidity +[ + balanceOf(0xbeef...), + balanceOf(0x1337...), + balanceOf(0x1111...) +] +``` + +### Dávkové schválení {#batch-approval} + +```solidity +// ERC-1155 +function setApprovalForAll( + address _operator, + bool _approved +) external; + +function isApprovedForAll( + address _owner, + address _operator +) external view returns (bool); +``` + +Schválení se mírně liší od ERC-20. Namísto schvalování konkrétních částek nastavíte operátora na schváleného nebo neschváleného pomocí `setApprovalForAll`. + +Aktuální stav lze zjistit pomocí `isApprovedForAll`. Jak můžete vidět, je to vše nebo nic. Nemůžete definovat, kolik tokenů schválit nebo dokonce kterou třídu tokenů. + +Tento design je záměrně jednoduchý. Můžete schválit pouze vše nebo nic pro jednu adresu. + +### Hák pro příjem {#receive-hook} + +```solidity +function onERC1155BatchReceived( + address _operator, + address _from, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external returns(bytes4); +``` + +Díky podpoře [EIP-165](https://eips.ethereum.org/EIPS/eip-165) podporuje ERC-1155 háky pro příjem pouze pro chytré kontrakty. Funkce háčku musí vrátit magickou předdefinovanou hodnotu bytes4, která je dána jako: + +```solidity +bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +``` + +Když přijímající kontrakt vrátí tuto hodnotu, předpokládá se, že kontrakt přijímá přenos a ví, jak zacházet s tokeny ERC-1155. Skvělé, už žádné tokeny zaseknuté v kontraktu! + +### Podpora NFT {#nft-support} + +Když je zásoba pouze jedna, token je v podstatě nezaměnitelný token (NFT). A stejně jako u standardu ERC-721 můžete definovat URL metadat. Klienti mohou adresu URL číst a upravovat, viz [zde](https://eips.ethereum.org/EIPS/eip-1155#metadata). + +### Pravidlo bezpečného převodu {#safe-transfer-rule} + +Už jsme se dotkli několika pravidel pro bezpečný přenos v předchozích vysvětleních. Podívejme se však na ta nejdůležitější z nich: + +1. Volající musí mít schválení k útratě tokenů pro adresu `_from` nebo se volající musí rovnat `_from`. +2. Volání přenosu musí být zrušeno, pokud + 1. Adresa `_to` je 0. + 2. délka `_ids` není stejná jako délka `_values`. + 3. zůstatek držitele některého z tokenů v `_ids` je nižší než odpovídající částka v `_values` odeslaná příjemci. + 4. Dojde k jakékoliv jiné chybě. + +_Poznámka_: Všechny dávkové funkce, včetně háku, existují také ve verzích bez dávkového zpracování. Je to takto nastaveno kvůli efektivitě využití paliva, protože přenos pouze jednoho aktiva bude pravděpodobně stále nejběžněji používaným způsobem. Pro zjednodušení jsme tyto funkce z článku vynechali, stejě jako pravidla bezpečného přenosu. Jejich jména jsou ale identická, stačí jen odstranit "Batch". + +## Další čtení {#further-reading} + +- [EIP-1155: Standard pro více tokenů](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: Dokumentace OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/erc1155) +- [ERC-1155: GitHub repozitář](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-1363/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-1363/index.md new file mode 100644 index 00000000000..bc56cf341cb --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-1363/index.md @@ -0,0 +1,213 @@ +--- +title: "Standard zaplatitelného tokenu ERC-1363" +description: "ERC-1363 je rozšiřující rozhraní pro tokeny ERC-20, které podporuje provádění vlastní logiky na kontraktu příjemce po převodech nebo na kontraktu plátce po schváleních, a to vše v rámci jediné transakce." +lang: cs +--- + +## Úvod {#introduction} + +### Co je ERC-1363? {#what-is-erc1363} + +ERC-1363 je rozšiřující rozhraní pro tokeny ERC-20, které podporuje provádění vlastní logiky na kontraktu příjemce po převodech nebo na kontraktu plátce po schváleních, a to vše v rámci jediné transakce. + +### Rozdíly oproti ERC-20 {#erc20-differences} + +Standardní operace ERC-20 jako `transfer`, `transferFrom` a `approve` neumožňují spuštění kódu na kontraktu příjemce nebo plátce bez samostatné transakce. +To vnáší složitost do vývoje uživatelského rozhraní a ztěžuje přijetí, protože uživatelé musí čekat na provedení první transakce a poté odeslat druhou. +Musí také dvakrát zaplatit palivo. + +ERC-1363 umožňuje, aby zastupitelné tokeny mohly snadněji provádět akce a fungovat bez použití jakéhokoli off-chain listeneru. +Umožňuje provést zpětné volání (callback) na kontraktu příjemce nebo plátce po převodu nebo schválení, a to v jediné transakci. + +## Předpoklady {#prerequisites} + +Pro lepší porozumění této stránce doporučujeme nejprve přečíst o: + +- [Standardy tokenů](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## Tělo {#body} + +ERC-1363 zavádí standardní API pro tokeny ERC-20 pro interakci s chytrými kontrakty po operacích `transfer`, `transferFrom` nebo `approve`. + +Tento standard poskytuje základní funkcionalitu pro převod tokenů a také umožňuje schválení tokenů, aby je mohla utratit jiná on-chain třetí strana, a poté provést zpětné volání (callback) na kontraktu příjemce nebo plátce. + +Existuje mnoho navrhovaných využití chytrých kontraktů, které mohou přijímat zpětná volání (callbacky) ERC-20. + +Mezi příklady patří: + +- **Hromadné prodeje (crowdsales)**: odeslané tokeny spouští okamžité přidělení odměny. +- **Služby**: platba aktivuje přístup ke službě v jednom kroku. +- **Faktury**: tokeny automaticky hradí faktury. +- **Předplatná**: schválení roční sazby aktivuje předplatné v rámci platby za první měsíc. + +Z těchto důvodů byl původně pojmenován **„zaplatitelný token“**. + +Chování zpětného volání (callback) dále rozšiřuje jeho užitečnost a umožňuje bezproblémové interakce, jako jsou: + +- **Staking (uzamčení)**: převedené tokeny spouštějí automatické uzamčení ve stakingovém kontraktu. +- **Hlasování**: přijaté tokeny registrují hlasy v systému správy. +- **Směna (swapping)**: schválení tokenů aktivuje logiku směny v jediném kroku. + +Tokeny ERC-1363 lze použít pro specifické účely ve všech případech, které vyžadují spuštění zpětného volání (callback) po přijatém převodu nebo schválení. +ERC-1363 je také užitečný pro zamezení ztráty nebo uzamčení tokenů v chytrých kontraktech ověřením schopnosti příjemce s tokeny nakládat. + +Na rozdíl od jiných návrhů na rozšíření ERC-20, ERC-1363 nepřepisuje metody `transfer` a `transferFrom` z ERC-20 a definuje ID rozhraní, která se mají implementovat, při zachování zpětné kompatibility s ERC-20. + +Z [EIP-1363](https://eips.ethereum.org/EIPS/eip-1363): + +### Metody {#methods} + +Chytré kontrakty implementující standard ERC-1363 **MUSÍ** implementovat všechny funkce v rozhraní `ERC1363` a také rozhraní `ERC20` a `ERC165`. + +```solidity +pragma solidity ^0.8.0; + +/** + * @title ERC1363 + * @dev Rozšiřující rozhraní pro tokeny ERC-20, které podporuje spouštění kódu na kontraktu příjemce + * po `transfer` nebo `transferFrom` nebo kódu na kontraktu plátce po `approve` v jediné transakci. + */ +interface ERC1363 is ERC20, ERC165 { + /* + * POZNÁMKA: Identifikátor ERC-165 pro toto rozhraní je 0xb0202a11. + * 0xb0202a11 === + * bytes4(keccak256('transferAndCall(address,uint256)')) ^ + * bytes4(keccak256('transferAndCall(address,uint256,bytes)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256)')) ^ + * bytes4(keccak256('transferFromAndCall(address,address,uint256,bytes)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256)')) ^ + * bytes4(keccak256('approveAndCall(address,uint256,bytes)')) + */ + + /** + * @dev Přesune množství tokenů `value` z účtu volajícího na adresu `to` + * a poté zavolá `ERC1363Receiver::onTransferReceived` na `to`. + * @param to Adresa, na kterou se tokeny převádějí. + * @param value Množství tokenů k převodu. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function transferAndCall(address to, uint256 value) external returns (bool); + + /** + * @dev Přesune množství tokenů `value` z účtu volajícího na adresu `to` + * a poté zavolá `ERC1363Receiver::onTransferReceived` na `to`. + * @param to Adresa, na kterou se tokeny převádějí. + * @param value Množství tokenů k převodu. + * @param data Dodatečná data bez specifikovaného formátu, odeslaná při volání na `to`. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function transferAndCall(address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Přesune množství tokenů `value` z `from` na `to` pomocí mechanismu povolenky + * a poté zavolá `ERC1363Receiver::onTransferReceived` na `to`. + * @param from Adresa, ze které se tokeny odesílají. + * @param to Adresa, na kterou se tokeny převádějí. + * @param value Množství tokenů k převodu. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function transferFromAndCall(address from, address to, uint256 value) external returns (bool); + + /** + * @dev Přesune množství tokenů `value` z `from` na `to` pomocí mechanismu povolenky + * a poté zavolá `ERC1363Receiver::onTransferReceived` na `to`. + * @param from Adresa, ze které se tokeny odesílají. + * @param to Adresa, na kterou se tokeny převádějí. + * @param value Množství tokenů k převodu. + * @param data Dodatečná data bez specifikovaného formátu, odeslaná při volání na `to`. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function transferFromAndCall(address from, address to, uint256 value, bytes calldata data) external returns (bool); + + /** + * @dev Nastaví množství tokenů `value` jako povolenku pro `spender` nad tokeny volajícího + * a poté zavolá `ERC1363Spender::onApprovalReceived` na `spender`. + * @param spender Adresa, která utratí prostředky. + * @param value Množství tokenů, které se mají utratit. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function approveAndCall(address spender, uint256 value) external returns (bool); + + /** + * @dev Nastaví množství tokenů `value` jako povolenku pro `spender` nad tokeny volajícího + * a poté zavolá `ERC1363Spender::onApprovalReceived` na `spender`. + * @param spender Adresa, která utratí prostředky. + * @param value Množství tokenů, které se mají utratit. + * @param data Dodatečná data bez specifikovaného formátu, odeslaná při volání na `spender`. + * @return Booleovská hodnota, která označuje, že operace byla úspěšná, pokud nevyvolá výjimku. + */ + function approveAndCall(address spender, uint256 value, bytes calldata data) external returns (bool); +} + +interface ERC20 { + event Transfer(address indexed from, address indexed to, uint256 value); + event Approval(address indexed owner, address indexed spender, uint256 value); + function transfer(address to, uint256 value) external returns (bool); + function transferFrom(address from, address to, uint256 value) external returns (bool); + function approve(address spender, uint256 value) external returns (bool); + function totalSupply() external view returns (uint256); + function balanceOf(address account) external view returns (uint256); + function allowance(address owner, address spender) external view returns (uint256); +} + +interface ERC165 { + function supportsInterface(bytes4 interfaceId) external view returns (bool); +} +``` + +Chytrý kontrakt, který chce přijímat tokeny ERC-1363 přes `transferAndCall` nebo `transferFromAndCall`, **MUSÍ** implementovat rozhraní `ERC1363Receiver`: + +```solidity +/** + * @title ERC1363Receiver + * @dev Rozhraní pro jakýkoli kontrakt, který chce podporovat `transferAndCall` nebo `transferFromAndCall` z kontraktů tokenů ERC-1363. + */ +interface ERC1363Receiver { + /** + * @dev Kdykoli jsou tokeny ERC-1363 převedeny na tento kontrakt přes `ERC1363::transferAndCall` nebo `ERC1363::transferFromAndCall` + * `operátorem` z `from`, je zavolána tato funkce. + * + * POZNÁMKA: Pro přijetí převodu musí tato funkce vrátit + * `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))` + * (tj. 0x88a7ca5c, nebo svůj vlastní selektor funkce). + * + * @param operator Adresa, která zavolala funkci `transferAndCall` nebo `transferFromAndCall`. + * @param from Adresa, ze které jsou tokeny převedeny. + * @param value Množství převedených tokenů. + * @param data Dodatečná data bez specifikovaného formátu. + * @return `bytes4(keccak256("onTransferReceived(address,address,uint256,bytes)"))`, pokud je převod povolen, jinak vyvolá výjimku. + */ + function onTransferReceived(address operator, address from, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +Chytrý kontrakt, který chce přijímat tokeny ERC-1363 přes `approveAndCall`, **MUSÍ** implementovat rozhraní `ERC1363Spender`: + +```solidity +/** + * @title ERC1363Spender + * @dev Rozhraní pro jakýkoli kontrakt, který chce podporovat `approveAndCall` z kontraktů tokenů ERC-1363. + */ +interface ERC1363Spender { + /** + * @dev Kdykoli `vlastník` tokenů ERC-1363 schválí tento kontrakt přes `ERC1363::approveAndCall` + * k utracení svých tokenů, je zavolána tato funkce. + * + * POZNÁMKA: Pro přijetí schválení musí tato funkce vrátit + * `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))` + * (tj. 0x7b04a2d0, nebo svůj vlastní selektor funkce). + * + * @param owner Adresa, která zavolala funkci `approveAndCall` a předtím vlastnila tokeny. + * @param value Množství tokenů, které se mají utratit. + * @param data Dodatečná data bez specifikovaného formátu. + * @return `bytes4(keccak256("onApprovalReceived(address,uint256,bytes)"))`, pokud je schválení povoleno, jinak vyvolá výjimku. + */ + function onApprovalReceived(address owner, uint256 value, bytes calldata data) external returns (bytes4); +} +``` + +## Další čtení {#further-reading} + +- [ERC-1363: Standard zaplatitelného tokenu](https://eips.ethereum.org/EIPS/eip-1363) +- [ERC-1363: Repozitář na GitHubu](https://github.com/vittominacori/erc1363-payable-token) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-20/index.md new file mode 100644 index 00000000000..f444ba706e0 --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-20/index.md @@ -0,0 +1,186 @@ +--- +title: Standard tokenu ERC-20 +description: "Seznamte se s ERC-20, standardem pro zaměnitelné tokeny na síti Ethereum, který umožňuje interoperabilní tokenové aplikace." +lang: cs +--- + +## Úvod {#introduction} + +**Co je to token?** + +Tokeny mohou v ekosystému Etherea reprezentovat prakticky cokoliv: + +- reputační body na online platformě +- dovednosti postavy ve hře +- finanční aktiva, jako je podíl ve společnosti +- fiat měnu, jako je USD +- unci zlata +- a více... + +Takováto mocná funkce Etherea musí být samozřejmě ošetřena robustním standardem, že? A právě zde hraje svou roli ERC-20! Tento standard umožňuje vývojářům vytvářet tokenové aplikace, které jsou interoperabilní s jinými produkty a službami. Standard ERC-20 se také používá k poskytnutí dodatečné funkcionality pro [ether](/glossary/#ether). + +**Co je ERC-20?** + +ERC-20 zavádí standard pro zaměnitelné tokeny, které, jinými slovy, mají vlastnost, díky níž je každý token naprosto stejný (typem i hodnotou) jako jiný token. ERC-20 token funguje stejně jako ETH, což znamená, že 1 token je a vždy bude roven všem ostatním tokenům. + +## Předpoklady {#prerequisites} + +- [Účty](/developers/docs/accounts) +- [Chytré kontrakty](/developers/docs/smart-contracts/) +- [Standardy tokenů](/developers/docs/standards/tokens/) + +## Tělo {#body} + +ERC-20 (Ethereum Request for Comments 20), navržený Fabianem Vogelstellerem v listopadu 2015, je tokenový standard, který implementuje API pro tokeny v rámci smart kontraktů. + +Příklady funkcionalit, které ERC-20 poskytuje: + +- převod tokenů z jednoho účtu na druhý +- získání informace o aktuálním zůstatku tokenů na účtu +- získání celkové nabídky tokenů dostupných v síti +- schválení, zda může být určitá částka tokenů z účtu použita třetí stranou + +Pokud smart kontrakt implementuje následující metody a události, může být nazván ERC-20 kontraktem a po spuštění bude zodpovědný za sledování tokenů vytvořených na Ethereu. + +Z [EIP-20](https://eips.ethereum.org/EIPS/eip-20): + +### Metody {#methods} + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) +``` + +### Události {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +### Příklady {#web3py-example} + +Podívejme se, proč je tento standard tak důležitý pro zjednodušení prohlížení jakéhokoliv kontraktu ERC-20 tokenu na Ethereu. +Abychom mohli vytvořit rozhraní pro jakýkoliv ERC-20 token, stačí nám Contract Application Binary Interface (ABI). Jak můžete vidět níže, použijeme zjednodušené ABI, abychom vám to ukázali na jednoduchém příkladu. + +#### Příklad Web3.py {#web3py-example} + +Nejprve se ujistěte, že máte nainstalovanou knihovnu Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation): + +``` +pip install web3 +``` + +```python +from web3 import Web3 + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) + +acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 + +# This is a simplified Contract Application Binary Interface (ABI) of an ERC-20 Token Contract. +# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'decimals', + 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) +symbol = dai_contract.functions.symbol().call() +decimals = dai_contract.functions.decimals().call() +totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals +addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# DAI +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) + +weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) +symbol = weth_contract.functions.symbol().call() +decimals = weth_contract.functions.decimals().call() +totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals +addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# WETH +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) +``` + +## Známé problémy {#erc20-issues} + +### Problém s příjmem tokenů ERC-20 {#reception-issue} + +**K 20. červnu 2024 byly kvůli tomuto problému ztraceny tokeny ERC-20 v hodnotě nejméně 83 656 418 $.** **Všimněte si, že čistá implementace ERC-20 je náchylná k tomuto problému, pokud nad rámec níže uvedeného standardu neimplementujete sadu dodatečných omezení.** + +Když jsou ERC-20 tokeny poslány do smart kontraktu, který není k práci s nimi konstruován, mohou být tyto tokeny ztraceny navždy. K tomu dochází, když přijímající kontrakt nemá funkci, která by rozpoznala příchozí tokeny, nebo na ně dokázala reagovat, a ve standardu ERC-20 neexistuje mechanismus, který by přijímající kontrakt upozornil na příchozí tokeny. Hlavní způsoby, jak může tento problém vzniknout, jsou: + +1. Mechanismus přenosu tokenů + +- ERC-20 tokeny jsou přenášeny pomocí funkcí transfer nebo transferFrom + - Když uživatel odešle tokeny na adresu kontraktu pomocí těchto funkcí, tokeny jsou přeneseny bez ohledu na to, zda je přijímající kontrakt navržen k jejich zpracování + +2. Nedostatek upozornění + - Přijímající kontrakt nedostává žádné upozornění nebo zpětné volání, že mu byly odeslány nějaké tokeny + - Pokud přijímající kontrakt postrádá mechanismus pro zpracování příchozích tokenů (například fallback funkci nebo speciální funkci pro správu přijetí tokenů), tokeny jsou fakticky na adrese tohoto kontraktu zaseknuté +3. Bez vestavěné manipulace + - Standard ERC-20 nemá povinnou funkci, kterou by přijímající kontrakty musely implementovat, což vede k situacím, kdy kontrakty nejsou schopny příchozí tokeny správně spravovat + +**Možná řešení** + +I když není možné tomuto problému s ERC-20 zcela zabránit, existují metody, které umožňují výrazně snížit možnost ztráty tokenů pro koncového uživatele: + +- Nejčastějším problémem je, když uživatel pošle tokeny na adresu samotného kontraktu tokenu (např. USDT vložené na adresu kontraktu tokenu USDT). Doporučuje se omezit funkci `transfer(..)` tak, aby takové pokusy o převod vrátila zpět. Zvažte přidání kontroly `require(_to != address(this));` v rámci implementace funkce `transfer(..)`. +- Funkce `transfer(..)` obecně není určena k vkládání tokenů do kontraktů. Vzor `approve(..) & transferFrom(..)` se namísto toho používá k vkládání tokenů ERC-20 do kontraktů. Je možné omezit funkci převodu tak, aby se s ní zakázalo vkládání tokenů do jakýchkoli kontraktů, může to však narušit kompatibilitu s kontrakty, které předpokládají, že tokeny lze vkládat do kontraktů pomocí funkce `trasnfer(..)` (např. u poolů likvidity Uniswap). +- Vždy předpokládejte, že tokeny ERC-20 mohou skončit ve vašem kontraktu, i když váš kontrakt nemá nikdy žádné přijímat. Na straně příjemce neexistuje žádný způsob, jak zabránit náhodným vkladům nebo je odmítnout. Doporučuje se implementovat funkci, která by umožnila extrahovat náhodně vložené tokeny ERC-20. +- Zvažte použití alternativních standardů tokenů. + +Z tohoto problému vzešly některé alternativní standardy, jako například [ERC-223](/developers/docs/standards/tokens/erc-223) nebo [ERC-1363](/developers/docs/standards/tokens/erc-1363). + +## Další čtení {#further-reading} + +- [EIP-20: Standard tokenu ERC-20](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin – Tokeny](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin – Implementace ERC-20](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy – Průvodce tokeny ERC20 v Solidity](https://www.alchemy.com/overviews/erc20-solidity) + +## Další standardy zaměnitelných tokenů {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-1363](/developers/docs/standards/tokens/erc-1363) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 – Tokenizované trezory](/developers/docs/standards/tokens/erc-4626) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..0e020138fa2 --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,198 @@ +--- +title: Standard tokenu ERC-223 +description: "Přehled standardu zastupitelných tokenů ERC-223, jak funguje a srovnání s ERC-20." +lang: cs +--- + +## Úvod {#introduction} + +### Co je ERC-223? {#what-is-erc223} + +ERC-223 je standard pro zastupitelné tokeny, podobný standardu ERC-20. Klíčový rozdíl spočívá v tom, že ERC-223 definuje nejen API tokenu, ale také logiku pro převod tokenů od odesílatele k příjemci. Zavádí komunikační model, který umožňuje zpracování převodů tokenů na straně příjemce. + +### Rozdíly oproti ERC-20 {#erc20-differences} + +ERC-223 řeší některá omezení ERC-20 a zavádí novou metodu interakce mezi kontraktem tokenu a kontraktem, který může tokeny přijímat. Existuje několik věcí, které jsou s ERC-223 možné, ale s ERC-20 ne: + +- Zpracování převodu tokenů na straně příjemce: Příjemci mohou zjistit, že je ukládán token ERC-223. +- Odmítnutí nesprávně odeslaných tokenů: Pokud uživatel odešle tokeny ERC-223 do kontraktu, který nemá tokeny přijímat, může kontrakt transakci odmítnout a zabránit tak ztrátě tokenů. +- Metadata v převodech: Tokeny ERC-223 mohou obsahovat metadata, což umožňuje k transakcím s tokeny připojit libovolné informace. + +## Předpoklady {#prerequisites} + +- [Účty](/developers/docs/accounts) +- [Chytré kontrakty](/developers/docs/smart-contracts/) +- [Standardy tokenů](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## Tělo {#body} + +ERC-223 je tokenový standard, který implementuje API pro tokeny v rámci chytrých kontraktů. Deklaruje také API pro kontrakty, které mají přijímat tokeny ERC-223. Kontrakty, které nepodporují rozhraní API ERC-223 Receiver, nemohou přijímat tokeny ERC-223, což zabraňuje chybám uživatelů. + +Pokud chytrý kontrakt implementuje následující metody a události, lze jej označit za kontrakt tokenu kompatibilní s ERC-223. Po nasazení +bude zodpovědný za sledování vytvořených tokenů na Ethereu. + +Kontrakt nemusí obsahovat pouze tyto funkce a vývojář může do tohoto kontraktu přidat jakoukoli jinou funkci z různých tokenových standardů. Například funkce `approve` a `transferFrom` nejsou součástí standardu ERC-223, ale v případě potřeby je lze implementovat. + +Z [EIP-223](https://eips.ethereum.org/EIPS/eip-223): + +### Metody {#methods} + +Token ERC-223 musí implementovat následující metody: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +Kontrakt, který má přijímat tokeny ERC-223, musí implementovat následující metodu: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +Pokud jsou tokeny ERC-223 odeslány do kontraktu, který neimplementuje funkci `tokenReceived(..)`, převod musí selhat a tokeny nesmí být přesunuty ze zůstatku odesílatele. + +### Události {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### Příklady {#examples} + +API tokenu ERC-223 je podobné API ERC-20, takže z hlediska vývoje uživatelského rozhraní zde není žádný rozdíl. Jedinou výjimkou je, že tokeny ERC-223 nemusí mít funkce `approve` + `transferFrom`, protože ty jsou pro tento standard volitelné. + +#### Příklady v Solidity {#solidity-example} + +Následující příklad ukazuje, jak funguje základní kontrakt tokenu ERC-223: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) {return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +Nyní chceme, aby jiný kontrakt přijímal vklady tokenu `tokenA` za předpokladu, že tokenA je tokenem ERC-223. Kontrakt musí přijímat pouze tokenA a odmítat všechny ostatní tokeny. Když kontrakt obdrží tokenA, musí emitovat událost `Deposit()` a zvýšit hodnotu interní proměnné `deposits`. + +Zde je kód: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // Jediný token, který chceme přijmout. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // Je důležité si uvědomit, že v rámci této funkce + // msg.sender je adresa tokenu, který je přijímán, + // msg.value je vždy 0, protože kontrakt tokenu ve většině případů nevlastní ani neposílá ether, + // _from je odesílatel převodu tokenu, + // _value je množství vložených tokenů. + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## Často kladené dotazy {#faq} + +### Co se stane, když do kontraktu pošleme nějaký tokenB? {#sending-tokens} + +Transakce selže a převod tokenů se neuskuteční. Tokeny budou vráceny na adresu odesílatele. + +### Jak můžeme na tento kontrakt provést vklad? {#contract-deposits} + +Zavolejte funkci `transfer(address,uint256)` nebo `transfer(address,uint256,bytes)` tokenu ERC-223 a zadejte adresu kontraktu `RecipientContract`. + +### Co se stane, když na tento kontrakt převedeme token ERC-20? {#erc-20-transfers} + +Pokud je na `RecipientContract` odeslán token ERC-20, tokeny budou převedeny, ale převod nebude rozpoznán (nebude spuštěna žádná událost `Deposit()` a hodnota vkladů se nezmění). Nežádoucí vklady ERC-20 nelze filtrovat ani jim zabránit. + +### Co když chceme po dokončení vkladu tokenu spustit nějakou funkci? {#function-execution} + +Existuje několik způsobů, jak toho dosáhnout. V tomto příkladu se budeme řídit metodou, díky níž jsou převody ERC-223 totožné s převody etheru: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // Jediný token, který chceme přijmout. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // Zpracujte příchozí transakci a proveďte následné volání funkce. + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +Když `RecipientContract` obdrží token ERC-223, spustí funkci zakódovanou jako parametr `_data` transakce tokenu, a to stejným způsobem, jakým transakce s etherem kódují volání funkcí jako transakční `data`. Pro více informací si přečtěte o [datovém poli](/developers/docs/transactions/#the-data-field). + +Ve výše uvedeném příkladu musí být token ERC-223 převeden na adresu kontraktu `RecipientContract` pomocí funkce `transfer(address,uin256,bytes calldata _data)`. Pokud bude datový parametr `0xc2985578` (podpis funkce `foo()`), pak bude po přijetí vkladu tokenu vyvolána funkce foo() a bude spuštěna událost Foo(). + +Parametry lze také zakódovat do `dat` převodu tokenu, například můžeme zavolat funkci bar() s hodnotou 12345 pro `_someNumber`. V tomto případě musí být `data` `0x0423a13200000000000000000000000000000000000000000000000000000000000004d2`, kde `0x0423a132` je podpis funkce `bar(uint256)` a `00000000000000000000000000000000000000000000000000000000000004d2` je 12345 jako uint256. + +## Omezení {#limitations} + +Ačkoli ERC-223 řeší několik problémů, které se vyskytují ve standardu ERC-20, není bez vlastních omezení: + +- Přijetí a kompatibilita: ERC-223 ještě není široce přijat, což může omezit jeho kompatibilitu se stávajícími nástroji a platformami. +- Zpětná kompatibilita: ERC-223 není zpětně kompatibilní s ERC-20, což znamená, že stávající kontrakty a nástroje ERC-20 nebudou s tokeny ERC-223 fungovat bez úprav. +- Náklady na palivo: Dodatečné kontroly a funkce v převodech ERC-223 mohou mít za následek vyšší náklady na palivo ve srovnání s transakcemi ERC-20. + +## Další čtení {#further-reading} + +- [EIP-223: Tokenový standard ERC-223](https://eips.ethereum.org/EIPS/eip-223) +- [Původní návrh ERC-223](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-4626/index.md new file mode 100644 index 00000000000..b9e09390174 --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-4626/index.md @@ -0,0 +1,227 @@ +--- +title: "Standard tokenizovaného trezoru ERC-4626" +description: "Standard pro výnosové trezory." +lang: cs +--- + +## Úvod {#introduction} + +ERC-4626 je standard, který optimalizuje a sjednocuje technické parametry výnosových trezorů. Poskytuje standardní API pro tokenizované výnosové trezory, které představují podíly na jednom základním tokenu ERC-20. ERC-4626 také definuje volitelné rozšíření pro tokenizované trezory využívající ERC-20, které nabízí základní funkce pro vkládání, vybírání tokenů a čtení zůstatků. + +**Role ERC-4626 ve výnosových trezorech** + +Trhy s půjčkami, agregátory a tokeny s vnitřním úročením pomáhají uživatelům dosáhnout největšího výnosu z jejich kryptotokenů. Tyto strategie se provádějí s mírnými variacemi, což může být náchylné k chybám nebo plýtvání vývojovými zdroji. + +ERC-4626 ve výnosových trezorech sníží náročnost integrace a otevře přístup k výnosům v různých aplikacích s minimálním specializovaným úsilím od vývojářů tím, že vytvoří konzistentnější a robustnější implementační vzory. + +Token ERC-4626 je plně popsán v [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626). + +**Asynchronní rozšíření trezoru (ERC-7540)** + +ERC-4626 je optimalizován pro atomické vklady a odkupy až do určitého limitu. Pokud je limitu dosaženo, nelze odeslat žádné nové vklady ani odkupy. Toto omezení nefunguje dobře pro žádný systém chytrých kontraktů s asynchronními akcemi nebo zpožděními jako předpokladem pro propojení s trezorem (např. protokoly reálných aktiv, protokoly pro půjčky s nedostatečným zajištěním, protokoly pro cross-chain půjčky, tokeny likvidního stakingu nebo bezpečnostní moduly pojištění). + +ERC-7540 rozšiřuje použitelnost trezorů ERC-4626 pro asynchronní případy použití. Stávající rozhraní trezoru (`deposit`/`withdraw`/`mint`/`redeem`) je plně využito k nárokování asynchronních požadavků. + +Rozšíření ERC-7540 je plně popsáno v [ERC-7540](https://eips.ethereum.org/EIPS/eip-7540). + +**Rozšíření trezoru s více aktivy (ERC-7575)** + +Jedním z chybějících případů použití, který ERC-4626 nepodporuje, jsou trezory, které mají více aktiv nebo vstupních bodů, jako jsou tokeny poskytovatele likvidity (LP). Ty jsou obecně těžkopádné nebo nevyhovující kvůli požadavku, aby samotný standard ERC-4626 byl ERC-20. + +ERC-7575 přidává podporu pro trezory s více aktivy externalizací implementace tokenu ERC-20 z implementace ERC-4626. + +Rozšíření ERC-7575 je plně popsáno v [ERC-7575](https://eips.ethereum.org/EIPS/eip-7575). + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky doporučujeme nejprve přečíst si o [standardech tokenů](/developers/docs/standards/tokens/) a [ERC-20](/developers/docs/standards/tokens/erc-20/). + +## Funkce a vlastnosti ERC-4626: {#body} + +### Metody {#methods} + +#### aktivum {#asset} + +```solidity +function asset() public view returns (address assetTokenAddress) +``` + +Tato funkce vrací adresu základního tokenu, který je používán pro účetnictví, vklady a výběry v trezoru. + +#### totalAssets {#totalassets} + +```solidity +function totalAssets() public view returns (uint256) +``` + +Tato funkce vrací celkové množství základních aktiv držených v trezoru. + +#### convertToShares {#convertoshares} + +```solidity +function convertToShares(uint256 assets) public view returns (uint256 shares) +``` + +Tato funkce vrací množství `shares`, které by trezor vyměnil za poskytnuté množství `assets`. + +#### convertToAssets {#convertoassets} + +```solidity +function convertToAssets(uint256 shares) public view returns (uint256 assets) +``` + +Tato funkce vrací množství `assets`, které by trezor vyměnil za poskytnuté množství `shares`. + +#### maxDeposit {#maxdeposit} + +```solidity +function maxDeposit(address receiver) public view returns (uint256 maxAssets) +``` + +Tato funkce vrací maximální množství podkladových aktiv, které lze vložit v jediném volání [`deposit`](#deposit), přičemž jsou podíly vyraženy pro `receiver`. + +#### previewDeposit {#previewdeposit} + +```solidity +function previewDeposit(uint256 assets) public view returns (uint256 shares) +``` + +Tato funkce umožňuje uživatelům simulovat účinky jejich vkladu v aktuálním bloku. + +#### deposit {#deposit} + +```solidity +function deposit(uint256 assets, address receiver) public returns (uint256 shares) +``` + +Tato funkce vkládá `assets` podkladových tokenů do trezoru a uděluje `receiver`ovi vlastnictví `shares`. + +#### maxMint {#maxmint} + +```solidity +function maxMint(address receiver) public view returns (uint256 maxShares) +``` + +Tato funkce vrací maximální množství podílů, které mohou být vyraženy v jediném volání [`mint`](#mint), přičemž jsou podíly vyraženy pro `receiver`. + +#### previewMint {#previewmint} + +```solidity +function previewMint(uint256 shares) public view returns (uint256 assets) +``` + +Tato funkce umožňuje uživatelům simulovat účinky své ražby v aktuálním bloku. + +#### mint {#mint} + +```solidity +function mint(uint256 shares, address receiver) public returns (uint256 assets) +``` + +Tato funkce razí přesně `shares` podílů trezoru `receiver`ovi, a to vložením `assets` podkladových tokenů. + +#### maxWithdraw {#maxwithdraw} + +```solidity +function maxWithdraw(address owner) public view returns (uint256 maxAssets) +``` + +Tato funkce vrací maximální množství podkladových aktiv, které lze vybrat ze zůstatku `owner`a jediným voláním [`withdraw`](#withdraw). + +#### previewWithdraw {#previewwithdraw} + +```solidity +function previewWithdraw(uint256 assets) public view returns (uint256 shares) +``` + +Tato funkce umožňuje uživatelům simulovat účinky svého výběru v aktuálním bloku. + +#### withdraw {#withdraw} + +```solidity +function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) +``` + +Tato funkce spálí `shares` od `owner`a a odešle z trezoru přesně `assets` tokenů `receiver`ovi. + +#### maxRedeem {#maxredeem} + +```solidity +function maxRedeem(address owner) public view returns (uint256 maxShares) +``` + +Tato funkce vrací maximální množství podílů, které lze odkoupit ze zůstatku `owner`a prostřednictvím volání [`redeem`](#redeem). + +#### previewRedeem {#previewredeem} + +```solidity +function previewRedeem(uint256 shares) public view returns (uint256 assets) +``` + +Tato funkce umožňuje uživatelům simulovat účinky svého odkupu v aktuálním bloku. + +#### redeem {#redeem} + +```solidity +function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) +``` + +Tato funkce odkoupí určitý počet `shares` od `owner`a a odešle `assets` podkladového tokenu z trezoru `receiver`ovi. + +#### totalSupply {#totalsupply} + +```solidity +function totalSupply() public view returns (uint256) +``` + +Vrací celkový počet neodkoupených podílů v trezoru v oběhu. + +#### balanceOf {#balanceof} + +```solidity +function balanceOf(address owner) public view returns (uint256) +``` + +Vrací celkové množství podílů v trezoru, které `owner` aktuálně má. + +### Mapa rozhraní {#mapOfTheInterface} + +![Mapa rozhraní ERC-4626](./map-of-erc-4626.png) + +### Události {#events} + +#### Událost vkladu + +**MUSÍ** být emitována při vložení tokenů do trezoru pomocí metod [`mint`](#mint) a [`deposit`](#deposit). + +```solidity +event Deposit( + address indexed sender, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +Kde `sender` je uživatel, který vyměnil `assets` za `shares` a převedl tyto `shares` na `owner`a. + +#### Událost výběru + +**MUSÍ** být emitována, když jsou podíly vybrány z trezoru vkladatelem v metodách [`redeem`](#redeem) nebo [`withdraw`](#withdraw). + +```solidity +event Withdraw( + address indexed sender, + address indexed receiver, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +Kde `sender` je uživatel, který spustil výběr a vyměnil `shares` ve vlastnictví `owner`a za `assets`. `receiver` je uživatel, který obdržel vybrané `assets`. + +## Další čtení {#further-reading} + +- [EIP-4626: Standard tokenizovaného trezoru](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626: GitHub repozitář](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-721/index.md new file mode 100644 index 00000000000..130d670a50b --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-721/index.md @@ -0,0 +1,255 @@ +--- +title: "Standard nezaměnitelného tokenu ERC-721" +description: "Zjistěte více o ERC-721, standardu pro nezaměnitelné tokeny (NFT), které představují jedinečná digitální aktiva na Ethereu." +lang: cs +--- + +## Úvod {#introduction} + +**Co je to nezaměnitelný token?** + +Nezaměnitelný token (Non-Fungible Token - NFT) je používán k identifikaci něčeho nebo někoho jedinečným způsobem. Tento typ tokenu je ideální pro použití na platformách, které nabízejí sběratelské předměty, přístupové klíče, loterijní lístky, číslovaná místa na koncertech a sportovních zápasech atd. Tento speciální typ tokenu má úžasné možnosti, a proto si zaslouží odpovídající standard, kterým je ERC-721! + +**Co je ERC-721?** + +ERC-721 zavádí standard pro NFT, jinými slovy, tento typ tokenu je jedinečný a může mít jinou hodnotu než jiný token ze stejného smart kontraktu, například z důvodu jeho stáří, vzácnosti nebo něčeho jinému, například jeho vzhledu. +Počkat, vzhledu? + +Ano! Všechny NFT mají proměnnou `uint256` s názvem `tokenId`, takže pro každý kontrakt ERC-721 musí být dvojice +`adresa kontraktu, uint256 tokenId` globálně jedinečná. Nicméně dapp může mít „konvertor“, který +používá `tokenId` jako vstup a na výstupu vrací obrázek něčeho skvělého, jako jsou zombie, zbraně, dovednosti nebo úžasné kočičky! + +## Předpoklady {#prerequisites} + +- [Účty](/developers/docs/accounts/) +- [Chytré kontrakty](/developers/docs/smart-contracts/) +- [Standardy tokenů](/developers/docs/standards/tokens/) + +## Tělo {#body} + +ERC-721 (Ethereum Request for Comments 721), navržený Williamem Entrikenem, Dieterem Shirleym, Jacobem Evansem a Nastassií Sachs v lednu 2018, je standard pro nezaměnitelné tokeny, který implementuje API pro tokeny v rámci smart kontraktů. + +Obsahuje funkce, jako je převod tokenů z jednoho účtu na druhý, zjištění aktuálního zůstatku tokenů na účtu, zjištění ethereovské adresy vlastníka konkrétního tokenu a také celkového množství tokenů dostupných v síti. +Kromě toho má i další funkce, jako je schválení, že určité množství tokenů z účtu může být přesunuto třetí stranou. + +Pokud smart kontrakt implementuje následující metody a události, může být nazván ERC-721 Non-Fungible Token Contract, a jakmile je spuštěn, bude zodpovědný za sledování vytvořených tokenů na Ethereu. + +Z [EIP-721](https://eips.ethereum.org/EIPS/eip-721): + +### Metody {#methods} + +```solidity + function balanceOf(address _owner) external view returns (uint256); + function ownerOf(uint256 _tokenId) external view returns (address); + function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; + function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; + function transferFrom(address _from, address _to, uint256 _tokenId) external payable; + function approve(address _approved, uint256 _tokenId) external payable; + function setApprovalForAll(address _operator, bool _approved) external; + function getApproved(uint256 _tokenId) external view returns (address); + function isApprovedForAll(address _owner, address _operator) external view returns (bool); +``` + +### Události {#events} + +```solidity + event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); + event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); + event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); +``` + +### Příklady {#web3py-example} + +Podívejme se, proč je tento standard tak důležitý pro zjednodušení prohlížení jakéhokoliv kontraktu ERC-721 tokenu na Ethereu. +Abychom mohli vytvořit rozhraní pro jakýkoliv ERC-721 token, stačí nám Contract Application Binary Interface (ABI). Jak můžete vidět níže, použijeme zjednodušené ABI, abychom vám to ukázali na jednoduchém příkladu. + +#### Příklad Web3.py {#web3py-example} + +Nejprve se ujistěte, že máte nainstalovanou knihovnu Python [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation): + +``` +pip install web3 +``` + +```python +from web3 import Web3 +from web3._utils.events import get_event_data + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # Kontrakt CryptoKitties + +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # Prodejní aukce CryptoKitties + +# Toto je zjednodušené binární rozhraní aplikace (ABI) kontraktu NFT ERC-721. +# Zpřístupní pouze metody: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'name', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'ownerOf', + 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, +] + +ck_extra_abi = [ + { + 'inputs': [], + 'name': 'pregnantKitties', + 'outputs': [{'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'name': '_kittyId', 'type': 'uint256'}], + 'name': 'isPregnant', + 'outputs': [{'name': '', 'type': 'bool'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) +name = ck_contract.functions.name().call() +symbol = ck_contract.functions.symbol().call() +kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() +print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") + +pregnant_kitties = ck_contract.functions.pregnantKitties().call() +print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") + +# Použití ABI události Převod k získání informací o převedených kočičkách. +tx_event_abi = { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'from', 'type': 'address'}, + {'indexed': False, 'name': 'to', 'type': 'address'}, + {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'Transfer', + 'type': 'event' +} + +# K filtrování protokolů potřebujeme podpis události +event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() + +logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [event_signature] +}) + +# Poznámky: +# - Pokud se nevrátí žádná událost Převod, zvyšte počet bloků z hodnoty 120. +# - Pokud jste nenašli žádnou událost Převod, můžete také zkusit získat tokenId na adrese: +# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events +# Kliknutím rozbalte protokoly události a zkopírujte její argument „tokenId“ +recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] + +if recent_tx: + kitty_id = recent_tx[0]['tokenId'] # Sem vložte „tokenId“ z výše uvedeného odkazu + is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() + print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") +``` + +Kontrakt CryptoKitties má několik zajímavých událostí, kromě těch standardních. + +Podívejme se na dvě z nich, `Pregnant` a `Birth`. + +```python +# Použití ABI událostí Pregnant a Birth k získání informací o nových kočičkách. +ck_extra_events_abi = [ + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}], + 'name': 'Pregnant', + 'type': 'event' + }, + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'kittyId', 'type': 'uint256'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'genes', 'type': 'uint256'}], + 'name': 'Birth', + 'type': 'event' + }] + +# K filtrování protokolů potřebujeme podpis události +ck_event_signatures = [ + w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), + w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), +] + +# Zde je událost Pregnant: +# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog +pregnant_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[0]] +}) + +recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] + +# Zde je událost Birth: +# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a +birth_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[1]] +}) + +recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] +``` + +## Populární NFT {#popular-nfts} + +- [Etherscan NFT Tracker](https://etherscan.io/nft-top-contracts) uvádí nejlepší NFT na Ethereu podle objemu převodů. +- [CryptoKitties](https://www.cryptokitties.co/) je hra zaměřená na chovná, sběratelská a neodolatelně roztomilá + stvoření, která nazýváme CryptoKitties. +- [Sorare](https://sorare.com/) je globální fantasy fotbalová hra, kde můžete sbírat sběratelské předměty z limitovaných edicí, + spravovat své týmy a soutěžit o ceny. +- [Služba názvů Etherea (ENS)](https://ens.domains/) nabízí bezpečný a decentralizovaný způsob adresování zdrojů + na blockchainu i mimo něj pomocí jednoduchých, lidsky čitelných jmen. +- [POAP](https://poap.xyz) doručuje bezplatné NFT lidem, kteří se účastní událostí nebo dokončí určité akce. POAPy můžete vytvořit i distribuovat zdarma. +- [Unstoppable Domains](https://unstoppabledomains.com/) je společnost se sídlem v San Franciscu, která vytváří domény na + blockchainech. Blockchainové domény nahrazují kryptoměnové adresy lidsky čitelnými jmény a mohou být použity k + vytváření webů odolných vůči cenzuře. +- [Gods Unchained Cards](https://godsunchained.com/) je sběratelská karetní hra (TCG) na blockchainu Ethereum, která využívá NFT k tomu, aby přinesla skutečné vlastnictví + herních aktiv. +- [Bored Ape Yacht Club](https://boredapeyachtclub.com) je sbírka 10 000 jedinečných NFT, která kromě toho, že je prokazatelně vzácným uměleckým dílem, funguje také jako členský token do klubu, který poskytuje členské výhody a benefity, jež se v čase zvyšují díky úsilí komunity. + +## Další čtení {#further-reading} + +- [EIP-721: Standard pro nezaměnitelné tokeny ERC-721](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin – dokumentace ERC-721](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin – implementace ERC-721](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [Alchemy NFT API](https://www.alchemy.com/docs/reference/nft-api-quickstart) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/cs/developers/docs/standards/tokens/erc-777/index.md new file mode 100644 index 00000000000..6a5d78a95b5 --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/erc-777/index.md @@ -0,0 +1,45 @@ +--- +title: Standard tokenu ERC-777 +description: "Seznamte se s ERC-777, vylepšeným standardem zaměnitelných tokenů s háčky, ačkoli z bezpečnostních důvodů je doporučeno používat ERC-20." +lang: cs +--- + +## Varování {#warning} + +**ERC-777 je obtížné správně implementovat kvůli jeho [náchylnosti k různým formám útoku](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2620). Doporučuje se místo něj použít [ERC-20](/developers/docs/standards/tokens/erc-20/).** Tato stránka zde zůstává jako historický archiv. + +## Úvod? {#introduction} + +ERC-777 je standard pro zaměnitelné tokeny, který vylepšuje stávající standard [ERC-20](/developers/docs/standards/tokens/erc-20/). + +## Předpoklady {#prerequisites} + +Pro lepší porozumění této stránce vám doporučujeme si nejprve přečíst o [ERC-20](/developers/docs/standards/tokens/erc-20/). + +## Jaká vylepšení navrhuje ERC-777 oproti ERC-20? {#-erc-777-vs-erc-20} + +ERC-777 poskytuje následující vylepšení oproti ERC-20. + +### Háčky {#hooks} + +Háčky jsou funkce popsané v kódu smart kontraktu. Háčky se volají, když jsou tokeny odesílány nebo přijímány prostřednictvím kontraktu. To umožňuje smart kontraktu reagovat na příchozí nebo odchozí tokeny. + +Háčky jsou registrovány a objevovány pomocí standardu [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820). + +#### Proč jsou háčky skvělé? {#why-are-hooks-great} + +1. Háčky umožňují odesílat tokeny do kontraktu a oznamovat to kontraktu v jediné transakci, na rozdíl od [ERC-20](https://eips.ethereum.org/EIPS/eip-20), který k dosažení tohoto cíle vyžaduje dvojí volání (`approve`/`transferFrom`). +2. Kontrakty, které nemají registrované háčky, nejsou kompatibilní s ERC-777. Když přijímací kontrakt nemá registrovaný háček, odesílací kontrakt přeruší transakci. Tím se zabrání neúmyslným převodům přrostředků do smart kontraktů, které nejsou ERC-777. +3. Háčky mohou transakce také odmítat. + +### Desetinná místa {#decimals} + +Standard také řeší zmatek kolem `decimals` způsobený v ERC-20. To vede k příjemnější vývojářské zkušenosti. + +### Zpětná kompatibilita s ERC-20 {#backwards-compatibility-with-erc-20} + +S ERC-777 kontrakty lze pracovat, jako by to byly ERC-20 kontrakty. + +## Další čtení {#further-reading} + +[EIP-777: Tokenový standard](https://eips.ethereum.org/EIPS/eip-777) diff --git a/public/content/translations/cs/developers/docs/standards/tokens/index.md b/public/content/translations/cs/developers/docs/standards/tokens/index.md new file mode 100644 index 00000000000..bd58a82576d --- /dev/null +++ b/public/content/translations/cs/developers/docs/standards/tokens/index.md @@ -0,0 +1,41 @@ +--- +title: Standardy pro tokeny +description: "Prozkoumejte tokenové standardy sítě Ethereum, včetně ERC-20, ERC-721 a ERC-1155, pro zaměnitelné a nezaměnitelné tokeny." +lang: cs +incomplete: true +--- + +## Úvod {#introduction} + +Mnoho vývojových standardů na Ethereu se zaměřuje na rozhraní pro tokeny. Tyto standardy pomáhají zajistit, že smart kontrakty zůstanou složitelné, takže když nový projekt vydá token, zůstane kompatibilní se stávajícími decentralizovanými burzami a aplikacemi. + +Tokenové standardy definují, jak se tokeny chovají a jak spolu interagují napříč ekosystémem Etherea. Usnadňují vývojářům práci, protože nemusí znovu objevovat kolo, a zajišťují, že tokeny bezproblémově fungují s peněženkami, burzami a platformami DeFi. Ať už se jedná o herní průmysl, správu nebo jiné případy použití, tyto standardy zajišťují konzistenci a díky nim je Ethereum více propojené. + +## Předpoklady {#prerequisites} + +- [Vývojářské standardy sítě Ethereum](/developers/docs/standards/) +- [Chytré kontrakty](/developers/docs/smart-contracts/) + +## Tokenové standardy {#token-standards} + +Zde jsou některé z nejpopulárnějších standardů pro tokeny na Ethereu: + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) – standardní rozhraní pro zaměnitelné (fungible) tokeny, jako jsou hlasovací tokeny, stakovací tokeny nebo virtuální měny. + +### Standardy NFT {#nft-standards} + +- [ERC-721](/developers/docs/standards/tokens/erc-721/) – standardní rozhraní pro nezaměnitelné tokeny, jako je listina k uměleckému dílu nebo písni. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – standard ERC-1155 umožňuje efektivnější obchody a seskupování transakcí, čímž se šetří náklady. Tento standard tokenů umožňuje vytvářet jak užitkové tokeny (například $BNB nebo $BAT), tak nezaměnitelné tokeny jako jsou CryptoPunks. + +Úplný seznam návrhů [ERC](https://eips.ethereum.org/erc). + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Související návody {#related-tutorials} + +- [Kontrolní seznam pro integraci tokenů](/developers/tutorials/token-integration-checklist/) _– Seznam věcí, které je třeba zvážit při interakci s tokeny._ +- [Pochopení smart kontraktu pro token ERC-20](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Úvod do nasazení vašeho prvního smart kontraktu na testnetu Etherea._ +- [Převody a schvalování tokenů ERC-20 pomocí smart kontraktu v jazyce Solidity](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– Jak používat smart kontrakt k interakci s tokenem pomocí jazyka Solidity._ +- [Implementace trhu s tokeny ERC-721 [návod]](/developers/tutorials/how-to-implement-an-erc721-market/) _– Jak nabídnout tokenizované položky k prodeji na decentralizovaném inzertním portálu._ diff --git a/public/content/translations/cs/developers/docs/storage/index.md b/public/content/translations/cs/developers/docs/storage/index.md new file mode 100644 index 00000000000..4320536f78e --- /dev/null +++ b/public/content/translations/cs/developers/docs/storage/index.md @@ -0,0 +1,216 @@ +--- +title: "Decentralizovaná úložiště" +description: "Přehled toho, co je decentralizované úložiště, a dostupné nástroje pro jeho integraci do dappek." +lang: cs +--- + +Na rozdíl od centralizovaného serveru, který provozuje jedna společnost nebo organizace, decentralizované úložné systémy sestávají z peer-to-peer sítě uživatelů-operátorů, kteří drží část celkových dat, čímž vytvářejí odolný systém sdílení souborů. Tyto systémy mohou být využívány v blockchainových aplikacích nebo v jakékoliv síti založené na peer-to-peer principu. + +Ethereum samotné může být využíváno jako decentralizovaný úložný systém, což se děje například při ukládání kódu ve všech smart kontraktech. Když ale přijde na velké objemy dat, Ethereum není navrženo k tomuto účelu. Řetězec neustále roste, ale v době psaní tohoto textu se velikost blockchainu Etherea pohybuje kolem 500 GB až 1 TB ([v závislosti na klientovi](https://etherscan.io/chartsync/chaindefault)) a každý uzel v síti musí být schopen uložit všechna tato data. Pokud by řetězec expandoval na velké objemy dat (řekněme 5 TB), nebylo by nadále možné zajistit funkčnost všech síťových uzlů. Náklady na nasazení tak velkého množství dat na hlavní síť by také byly neúměrně vysoké kvůli poplatkům za [gas](/developers/docs/gas). + +Z těchto důvodů potřebujeme jiný řetězec nebo metodologii k ukládání velkých objemů dat decentralizovaným způsobem. + +Při zvažování možností decentralizovaného úložiště (dStorage) musí uživatel vzít v úvahu několik věcí. + +- Mechanismus uchovávání / pobídková struktura +- Vymáhání uchovávání dat +- Decentralizace +- Konsenzus + +## Mechanismus perzistence / pobídková struktura {#persistence-mechanism} + +### Na bázi blockchainu {#blockchain-based} + +Aby mohl kus dat přetrvat navždy, musíme použít mechanismus uchovávání. Například na Ethereu je tento mechanismus založen na tom, že celý řetězec musí být zohledněn při provozování síťového uzlu. Nové kusy dat jsou přidávány na konec řetězce, který neustále roste - což vyžaduje, aby každý uzel replikoval všechna vložená data. + +Toto je známé jako **perzistence na bázi blockchainu**. + +Problém s perzistencí na bázi blockchainu je v tom, že by se blockchain mohl příliš rozrůst, aby bylo možné všechna data reálně udržovat a ukládat (např. [mnoho zdrojů](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) odhaduje, že internet vyžaduje kapacitu úložiště přes 40 zettabytů). + +I blockchain musí mít nějaký typ pobídkové struktury. V případě uchovávání založeném na blockchainu se platí validátorovi. Když jsou data přidána do řetězce, validátoři jsou placeni za jejich přidání. + +Platformy s uchováváním založeným na blockchainu: + +- Ethereum +- [Arweave](https://www.arweave.org/) + +### Na bázi kontraktů {#contract-based} + +**Perzistence na bázi kontraktů** vychází z myšlenky, že data nemohou být replikována každým uzlem a ukládána navždy, ale místo toho musí být udržována prostřednictvím smluvních dohod. Tyto dohody jsou uzavírány s více uzly, které se zavázaly uchovávat kus dat po určitou dobu. Data musí být obnovena nebo refundována, kdykoli vyprší, aby byla zachována jejich existence. + +Ve většině případů se místo ukládání všech dat on-chain ukládá na blockchain pouze haš, který odkazuje na umístění dat. Tímto způsobem není třeba, aby celý řetězec rostl kvůli ukládání všech dat. + +Platformy s uchováváním založeným na kontraktu: + +- [Filecoin](https://docs.filecoin.io/basics/what-is-filecoin) +- [Skynet](https://sia.tech/) +- [Storj](https://storj.io/) +- [Züs](https://zus.network/) +- [Crust Network](https://crust.network) +- [Swarm](https://www.ethswarm.org/) +- [4EVERLAND](https://www.4everland.org/) + +### Další aspekty {#additional-consideration} + +IPFS je distribuovaný systém pro ukládání a přístup k souborům, webovým stránkám, aplikacím a datům. Nemá zabudovaný motivační systém, ale může být použit s jakýmkoli z výše uvedených řešení založených na kontraktech pro dlouhodobé uchování dat. Dalším způsobem, jak uchovat data na IPFS, je spolupráce s pinningovou službou, která vaše data „připne“. Můžete také provozovat vlastní IPFS uzel a přispívat do sítě, abyste uchovali svá nebo cizí data zdarma! + +- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) +- [Pinata](https://www.pinata.cloud/) _(pinovací služba IPFS)_ +- [web3.storage](https://web3.storage/) _(pinovací služba pro IPFS/Filecoin)_ +- [Infura](https://infura.io/product/ipfs) _(pinovací služba IPFS)_ +- [IPFS Scan](https://ipfs-scan.io) _(prohlížeč pinů IPFS)_ +- [4EVERLAND](https://www.4everland.org/) _(pinovací služba IPFS)_ +- [Filebase](https://filebase.com) _(pinovací služba IPFS)_ +- [Spheron Network](https://spheron.network/) _(pinovací služba pro IPFS/Filecoin)_ + +SWARM je decentralizovaná technologie pro ukládání a distribuci dat s motivačním systémem a orákulem pro stanovení ceny za pronájem úložiště. + +## Uchovávání dat {#data-retention} + +Aby systémy mohly uchovávat data, musí mít nějaký mechanismus, který zajistí, že data budou uchována. + +### Mechanismus výzvy {#challenge-mechanism} + +Jedním z nejpopulárnějších způsobů, jak zajistit uchování dat, je použití nějakého typu kryptografické výzvy, která je poskytnuta síťovým uzlům, aby se ověřilo, zda stále mají data. Jednoduchým příkladem je proof-of-access od Arweave. Uzel je vyzván, aby prokázal, že má data jak z nejnovějšího bloku, tak z náhodného bloku z minulosti. Pokud uzel nemůže přijít s odpovědí, je penalizován. + +Typy dStorage s mechanismem výzvy: + +- Züs +- Skynet +- Arweave +- Filecoin +- Crust Network +- 4EVERLAND + +### Decentralizace {#decentrality} + +Neexistují skvělé nástroje pro měření úrovně decentralizace platforem, ale obecně platí, že byste měli používat nástroje, které nevyžadují nějakou formu KYC, což je důkaz, že nejsou centralizované. + +Decentralizované nástroje bez KYC: + +- Skynet +- Arweave +- Filecoin +- IPFS +- Ethereum +- Crust Network +- 4EVERLAND + +### Konsenzus {#consensus} + +Většina těchto nástrojů má vlastní verzi [mechanismu konsensu](/developers/docs/consensus-mechanisms/), ale obecně jsou založeny buď na [**důkazu prací (PoW)**](/developers/docs/consensus-mechanisms/pow/), nebo na [**důkazu podílem (PoS)**](/developers/docs/consensus-mechanisms/pos/). + +Založeno na proof of work: + +- Skynet +- Arweave + +Založeno na proof of stake: + +- Ethereum +- Filecoin +- Züs +- Crust Network + +## Související nástroje {#related-tools} + +**IPFS – _meziplanetární souborový systém (InterPlanetary File System) je decentralizované úložiště a systém odkazů na soubory pro Ethereum._** + +- [Ipfs.io](https://ipfs.io/) +- [Dokumentace](https://docs.ipfs.io/) +- [GitHub](https://github.com/ipfs/ipfs) + +**Storj DCS – _bezpečné, soukromé a s S3 kompatibilní decentralizované cloudové objektové úložiště pro vývojáře._** + +- [Storj.io](https://storj.io/) +- [Dokumentace](https://docs.storj.io/) +- [GitHub](https://github.com/storj/storj) + +**Sia – _využívá kryptografii k vytvoření tržiště s cloudovým úložištěm, které nevyžaduje důvěru a umožňuje kupujícím a prodávajícím obchodovat přímo._** + +- [Skynet.net](https://sia.tech/) +- [Dokumentace](https://docs.sia.tech/) +- [GitHub](https://github.com/SiaFoundation/) + +**Filecoin – _Filecoin byl vytvořen stejným týmem, který stojí za IPFS. Je to pobídková vrstva nad ideály IPFS._** + +- [Filecoin.io](https://filecoin.io/) +- [Dokumentace](https://docs.filecoin.io/) +- [GitHub](https://github.com/filecoin-project/) + +**Arweave – _Arweave je platforma dStorage (decentralizované úložiště) pro ukládání dat._** + +- [Arweave.org](https://www.arweave.org/) +- [Dokumentace](https://docs.arweave.org/info/) +- [Arweave](https://github.com/ArweaveTeam/arweave/) + +**Züs – _Züs je dStorage platforma s důkazem podílem (proof-of-stake), tříštěním (sharding) a tzv. blobbery._** + +- [zus.network](https://zus.network/) +- [Dokumentace](https://docs.zus.network/zus-docs/) +- [GitHub](https://github.com/0chain/) + +**Crust Network – _Crust je dStorage platforma postavená na IPFS._** + +- [Crust.network](https://crust.network) +- [Dokumentace](https://wiki.crust.network) +- [GitHub](https://github.com/crustio) + +**Swarm – _distribuovaná úložná platforma a služba pro distribuci obsahu pro web3 stack Etherea._** + +- [EthSwarm.org](https://www.ethswarm.org/) +- [Dokumentace](https://docs.ethswarm.org/) +- [GitHub](https://github.com/ethersphere/) + +**OrbitDB – _decentralizovaná peer-to-peer databáze postavená na IPFS._** + +- [OrbitDB.org](https://orbitdb.org/) +- [Dokumentace](https://github.com/orbitdb/field-manual/) +- [GitHub](https://github.com/orbitdb/orbit-db/) + +**Aleph.im – _decentralizovaný cloudový projekt (databáze, souborové úložiště, výpočetní výkon a DID). Unikátní kombinace off-chain a on-chain peer-to-peer technologií. Kompatibilita s IPFS a více blockchainy._** + +- [Aleph.im](https://aleph.cloud/) +- [Dokumentace](https://docs.aleph.cloud/) +- [GitHub](https://github.com/aleph-im/) + +**Ceramic – _uživatelsky řízené databázové úložiště IPFS pro poutavé aplikace s velkým množstvím dat._** + +- [Ceramic.network](https://ceramic.network/) +- [Dokumentace](https://developers.ceramic.network/) +- [GitHub](https://github.com/ceramicnetwork/js-ceramic/) + +**Filebase – _decentralizované úložiště kompatibilní s S3 a geograficky redundantní pinovací služba pro IPFS. Všechny soubory nahrané do IPFS přes Filebase jsou automaticky pinovány na infrastrukturu Filebase s 3x replikací po celém světě._** + +- [Filebase.com](https://filebase.com/) +- [Dokumentace](https://docs.filebase.com/) +- [GitHub](https://github.com/filebase) + +**4EVERLAND – _cloudová výpočetní platforma pro Web 3.0, která integruje základní schopnosti úložiště, výpočetního výkonu a sítě, je kompatibilní s S3 a poskytuje synchronní ukládání dat v decentralizovaných úložných sítích, jako jsou IPFS a Arweave._** + +- [4everland.org](https://www.4everland.org/) +- [Dokumentace](https://docs.4everland.org/) +- [GitHub](https://github.com/4everland) + +**Kaleido – _platforma typu blockchain jako služba (BaaS) s IPFS uzly na jedno kliknutí._** + +- [Kaleido](https://kaleido.io/) +- [Dokumentace](https://docs.kaleido.io/kaleido-services/ipfs/) +- [GitHub](https://github.com/kaleido-io) + +**Spheron Network – _Spheron je platforma jako služba (PaaS) určená pro dApps, které chtějí spouštět své aplikace na decentralizované infrastruktuře s nejlepším výkonem. Poskytuje výpočetní výkon, decentralizované úložiště, CDN a webhosting ihned k použití._** + +- [spheron.network](https://spheron.network/) +- [Dokumentace](https://docs.spheron.network/) +- [GitHub](https://github.com/spheronFdn) + +## Další čtení {#further-reading} + +- [Co je to decentralizované úložiště?](https://coinmarketcap.com/academy/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) – _CoinMarketCap_ +- [Boření pěti běžných mýtů o decentralizovaném úložišti](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) – _Storj_ + +_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/)