From 8cf62cc5e49a2f73cb9511867973bd72a7830129 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:16:42 +0000 Subject: [PATCH 1/2] i18n(cs): translation import part 05 of 13 (24 files) --- .../client-diversity/index.md | 132 +++++ .../docs/nodes-and-clients/index.md | 319 ++++++++++++ .../nodes-and-clients/light-clients/index.md | 61 +++ .../node-architecture/index.md | 59 +++ .../nodes-as-a-service/index.md | 418 +++++++++++++++ .../nodes-and-clients/run-a-node/index.md | 484 ++++++++++++++++++ .../cs/developers/docs/oracles/index.md | 433 ++++++++++++++++ .../docs/programming-languages/dart/index.md | 33 ++ .../programming-languages/delphi/index.md | 56 ++ .../programming-languages/dot-net/index.md | 86 ++++ .../programming-languages/elixir/index.md | 55 ++ .../programming-languages/golang/index.md | 84 +++ .../docs/programming-languages/index.md | 33 ++ .../docs/programming-languages/java/index.md | 64 +++ .../programming-languages/javascript/index.md | 72 +++ .../programming-languages/python/index.md | 99 ++++ .../docs/programming-languages/ruby/index.md | 60 +++ .../docs/programming-languages/rust/index.md | 65 +++ .../cs/developers/docs/scaling/index.md | 68 +-- .../docs/scaling/optimistic-rollups/index.md | 128 ++--- .../developers/docs/scaling/plasma/index.md | 93 ++-- .../docs/scaling/sidechains/index.md | 52 +- .../docs/scaling/state-channels/index.md | 62 +-- .../developers/docs/scaling/validium/index.md | 95 ++-- 24 files changed, 2864 insertions(+), 247 deletions(-) create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/index.md create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/light-clients/index.md create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/node-architecture/index.md create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/nodes-as-a-service/index.md create mode 100644 public/content/translations/cs/developers/docs/nodes-and-clients/run-a-node/index.md create mode 100644 public/content/translations/cs/developers/docs/oracles/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/dart/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/delphi/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/elixir/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/golang/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/java/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/javascript/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/python/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/ruby/index.md create mode 100644 public/content/translations/cs/developers/docs/programming-languages/rust/index.md diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md new file mode 100644 index 00000000000..d9b537dbc1e --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/client-diversity/index.md @@ -0,0 +1,132 @@ +--- +title: "Rozmanitost klientů" +description: "Vysvětlení důležitosti diverzity klientů Etherea na vysoké úrovni." +lang: cs +sidebarDepth: 2 +--- + +Chování uzlu sítě Ethereum je řízeno klientským softwarem, který na něm běží. Existuje několik klientů sítě Ethereum na produkční úrovni, přičemž každý z nich je vyvíjen a udržován v různých jazycích samostatnými týmy. Klienti jsou vytvořeni podle společné specifikace, která zajišťuje, že mezi sebou bezproblémově komunikují, mají stejnou funkcionalitu a poskytují ekvivalentní uživatelskou zkušenost. V současné době však distribuce klientů napříč uzly není dostatečně rovnoměrná, aby se toto posílení sítě využilo v plném rozsahu. V ideálním případě by se uživatelé měli zhruba rovnoměrně rozdělit mezi různé klienty, aby síti zajistili co největší diverzitu klientů. + +## Předpoklady {#prerequisites} + +Pokud ještě nerozumíte tomu, co jsou uzly a klienti, podívejte se na [uzly a klienty](/developers/docs/nodes-and-clients/). [Exekuční](/glossary/#execution-layer) a [konsensuální](/glossary/#consensus-layer) vrstvy jsou definovány ve slovníku. + +## Proč existuje více klientů? {#why-multiple-clients} + +Existuje více nezávisle vyvíjených a udržovaných klientů, protože diverzita klientů činí síť odolnější vůči útokům a chybám. Více klientů je silnou stránkou, kterou má pouze Ethereum – ostatní blockchainy se spoléhají na neomylnost jediného klienta. Nestačí však mít k dispozici pouze více klientů, musí je přijmout komunita a celkový počet aktivních uzlů musí být mezi nimi relativně rovnoměrně rozložen. + +## Proč je diverzita klientů důležitá? {#client-diversity-importance} + +Existence mnoha nezávisle vyvíjených a udržovaných klientů je pro zdraví decentralizované sítě životně důležitá. Pojďme se podívat na důvody, proč tomu tak je. + +### Chyby {#bugs} + +Chyba v jednotlivém klientovi představuje pro síť menší riziko, když představuje menšinu uzlů sítě Ethereum. Při zhruba rovnoměrném rozložení uzlů mezi mnoho klientů je pravděpodobnost, že by většina klientů trpěla společným problémem, malá, a síť je díky tomu robustnější. + +### Odolnost vůči útokům {#resilience} + +Diverzita klientů také nabízí odolnost vůči útokům. Například útok, který [přiměje konkrétního klienta](https://twitter.com/vdWijden/status/1437712249926393858) k přechodu na konkrétní větev řetězce, má malou šanci na úspěch, protože ostatní klienti pravděpodobně nebudou zneužitelní stejným způsobem a kanonický řetězec zůstane neporušený. Nízká diverzita klientů zvyšuje riziko spojené s hackem dominantního klienta. Diverzita klientů se již osvědčila jako důležitá obrana proti škodlivým útokům na síť. Například útok typu denial-of-service v Šanghaji v roce 2016 byl možný, protože útočníci dokázali přimět dominantního klienta (Geth) k provedení pomalé I/O operace na disku desítky tisíckrát za blok. Protože byly online i alternativní klienti, kteří tuto zranitelnost nesdíleli, bylo Ethereum schopno útoku odolat a pokračovat v provozu, zatímco byla opravena zranitelnost v Gethu. + +### Finalita u důkazu podílem {#finality} + +Chyba v konsensuálním klientovi, který by používalo více než 33 % uzlů sítě Ethereum, by mohla zabránit finalizaci konsensuální vrstvy, což znamená, že by uživatelé nemohli věřit, že transakce nebudou v určitém okamžiku vráceny nebo změněny. To by bylo velmi problematické pro mnoho aplikací postavených na Ethereu, zejména pro DeFi. + + A co je horší, kritická chyba v klientovi s dvoutřetinovou většinou by mohla způsobit nesprávné rozdělení a finalizaci řetězce, což by vedlo k tomu, že by se velká skupina validátorů zasekla na neplatném řetězci. Pokud se tito validátoři chtějí znovu připojit ke správnému řetězci, čelí slashingu nebo pomalému a nákladnému dobrovolnému odchodu a reaktivaci. Velikost slashingu se odvíjí od počtu provinilých uzlů, přičemž dvoutřetinová většina je penalizována maximálně (32 ETH). + +Přestože se jedná o nepravděpodobné scénáře, ekosystém Etherea může jejich riziko zmírnit vyrovnáním distribuce klientů mezi aktivními uzly. V ideálním případě by žádný konsensuální klient nikdy neměl dosáhnout 33% podílu na celkovém počtu uzlů. + +### Sdílená odpovědnost {#responsibility} + +Existence majoritních klientů si vybírá i lidskou daň. Znamená to nadměrnou zátěž a odpovědnost pro malý vývojářský tým. Čím menší je diverzita klientů, tím větší je břemeno odpovědnosti pro vývojáře, kteří udržují majoritního klienta. Rozdělení této odpovědnosti mezi více týmů je dobré jak pro zdraví sítě uzlů Etherea, tak pro jeho síť lidí. + +## Současná diverzita klientů {#current-client-diversity} + +### Exekuční klienti {#execution-clients-breakdown} + + + +### Konsensuální klienti {#consensus-clients-breakdown} + + + +Tento diagram může být zastaralý – aktuální informace naleznete na [ethernodes.org](https://ethernodes.org) a [clientdiversity.org](https://clientdiversity.org). + +Dva výše uvedené koláčové grafy ukazují snímky současné diverzity klientů pro exekuční a konsensuální vrstvu (v době psaní v říjnu 2025). Diverzita klientů se v průběhu let zlepšila a v exekuční vrstvě došlo ke snížení dominance klienta [Geth](https://geth.ethereum.org/), v těsném závěsu je [Nethermind](https://www.nethermind.io/nethermind-client), třetí [Besu](https://besu.hyperledger.org/) a čtvrtý [Erigon](https://github.com/ledgerwatch/erigon), přičemž ostatní klienti tvoří méně než 3 % sítě. Nejčastěji používaný klient na konsensuální vrstvě – [Lighthouse](https://lighthouse.sigmaprime.io/) – je poměrně blízko druhému nejpoužívanějšímu. [Prysm](https://prysmaticlabs.com/#projects) a [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) tvoří přibližně 31 %, respektive 14 %, a ostatní klienti jsou používáni zřídka. + +Data o exekuční vrstvě byla získána z [supermajority.info](https://supermajority.info/) dne 26. října 2025. Data pro konsensuální klienty byla získána od [Michaela Sproula](https://github.com/sigp/blockprint). Data konsensuálních klientů je obtížnější získat, protože klienti konsensuální vrstvy nemají vždy jednoznačné stopy, které lze použít k jejich identifikaci. Data byla vygenerována pomocí klasifikačního algoritmu, který si někdy plete některé menšinové klienty (více podrobností naleznete [zde](https://twitter.com/sproulM_/status/1440512518242197516)). Ve výše uvedeném diagramu jsou tyto nejednoznačné klasifikace označeny štítkem typu buď/nebo (např. Nimbus/Teku). Nicméně je zřejmé, že na většině sítě běží Prysm. Přestože se jedná pouze o snímky, hodnoty v diagramu poskytují dobrý obecný přehled o současném stavu diverzity klientů. + +Aktuální data o diverzitě klientů pro konsensuální vrstvu jsou nyní k dispozici na [clientdiversity.org](https://clientdiversity.org/). + +## Exekuční vrstva {#execution-layer} + +Dosud se konverzace o diverzitě klientů zaměřovala především na konsensuální vrstvu. Nicméně exekuční klient [Geth](https://geth.ethereum.org) v současné době tvoří přibližně 85 % všech uzlů. Toto procento je problematické ze stejných důvodů jako u konsensuálních klientů. Například chyba v Gethu, která ovlivňuje zpracování transakcí nebo vytváření exekučních payloadů, by mohla vést k tomu, že by konsensuální klienti finalizovali problematické nebo chybné transakce. Proto by Ethereum bylo zdravější s rovnoměrnějším rozložením exekučních klientů, přičemž v ideálním případě by žádný klient neměl představovat více než 33 % sítě. + +## Používejte menšinového klienta {#use-minority-client} + +Řešení diverzity klientů vyžaduje více než jen to, aby si jednotliví uživatelé vybírali menšinové klienty – vyžaduje to také, aby klienta změnily pooly validátorů a instituce, jako jsou hlavní dapps a burzy. Každý uživatel se však může podílet na nápravě současné nerovnováhy a normalizaci používání veškerého dostupného softwaru Etherea. Po sloučení (The Merge) budou všichni provozovatelé uzlů muset provozovat exekučního klienta a konsensuálního klienta. Volba kombinací níže navržených klientů pomůže zvýšit diverzitu klientů. + +### Exekuční klienti {#execution-clients} + +- [Besu](https://www.hyperledger.org/use/besu) +- [Nethermind](https://downloads.nethermind.io/) +- [Erigon](https://github.com/ledgerwatch/erigon) +- [Go-Ethereum](https://geth.ethereum.org/) +- [Reth](https://reth.rs/) + +### Konsensuální klienti {#consensus-clients} + +- [Nimbus](https://nimbus.team/) +- [Lighthouse](https://github.com/sigp/lighthouse) +- [Teku](https://consensys.io/teku) +- [Lodestar](https://github.com/ChainSafe/lodestar) +- [Prysm](https://prysm.offchainlabs.com/docs/) +- [Grandine](https://docs.grandine.io/) + +Technicky zdatní uživatelé mohou tento proces urychlit tím, že budou psát více návodů a dokumentace pro menšinové klienty a povzbuzovat své kolegy provozující uzly k přechodu od dominantních klientů. Průvodci přechodem na menšinového konsensuálního klienta jsou k dispozici na [clientdiversity.org](https://clientdiversity.org/). + +## Nástěnky diverzity klientů {#client-diversity-dashboards} + +Několik nástěnek poskytuje statistiky o diverzitě klientů v reálném čase pro exekuční a konsensuální vrstvu. + +**Konsensuální vrstva:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) + +**Exekuční vrstva:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## Další čtení {#further-reading} + +- [Diverzita klientů na konsensuální vrstvě Etherea](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [Sloučení Etherea: Provozujte majoritního klienta na vlastní nebezpečí!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 24. března 2022_ +- [Důležitost diverzity klientů](https://our.status.im/the-importance-of-client-diversity/) +- [Seznam služeb uzlů Etherea](https://ethereumnodes.com/) +- [Problém diverzity klientů metodou „Pěti proč“](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [Diverzita Etherea a jak ji řešit (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## Související témata {#related-topics} + +- [Provozovat uzel Etherea](/run-a-node/) +- [Uzly a klienti](/developers/docs/nodes-and-clients/) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/index.md new file mode 100644 index 00000000000..5f143703cd5 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/index.md @@ -0,0 +1,319 @@ +--- +title: " Uzly a klienty" +description: "Přehled uzlů a klientského softwaru Etherea, plus jak nastavit uzel a proč byste to měli dělat." +lang: cs +sidebarDepth: 2 +--- + +Ethereum je distribuovaná síť počítačů (známých jako uzly), na kterých běží software, jenž dokáže ověřovat bloky a transakční data. Tento software musí být spuštěn na vašem počítači, aby se z něj stal uzel sítě Ethereum. K vytvoření uzlu jsou zapotřebí dva samostatné softwarové programy (známé jako „klienti“). + +## Předpoklady {#prerequisites} + +Než se ponoříte hlouběji a spustíte si vlastní instanci klienta Etherea, měli byste rozumět konceptu peer-to-peer sítě a [základům EVM](/developers/docs/evm/). Podívejte se na náš [úvod do Etherea](/developers/docs/intro-to-ethereum/). + +Pokud jste v problematice uzlů nováčkem, doporučujeme vám, abyste si nejprve přečetli náš uživatelsky přívětivý úvod na téma [provozování uzlu Etherea](/run-a-node). + +## Co jsou uzly a klienti? {#what-are-nodes-and-clients} + +„Uzel“ je jakákoli instance klientského softwaru Etherea, která je připojena k jiným počítačům, na nichž také běží software Etherea, a tvoří tak síť. Klient je implementace Etherea, která ověřuje data podle pravidel protokolu a udržuje síť bezpečnou. Uzel musí provozovat dva klienty: konsensuálního klienta a exekučního klienta. + +- Exekuční klient (známý také jako exekuční engine, EL klient nebo dříve klient Eth1) naslouchá novým transakcím vysílaným v síti, provádí je v EVM a uchovává nejnovější stav a databázi všech aktuálních dat Etherea. +- Konsensuální klient (známý také jako Beacon Node, CL klient nebo dříve klient Eth2) implementuje konsensuální algoritmus proof-of-stake, který umožňuje síti dosáhnout shody na základě ověřených dat z exekučního klienta. Existuje také třetí softwarový program známý jako „validátor“, který lze přidat ke konsensuálnímu klientovi a který uzlu umožňuje podílet se na zabezpečení sítě. + +Tito klienti spolupracují, aby sledovali čelo řetězce Etherea a umožnili uživatelům interakci se sítí Ethereum. Modulární návrh s více softwarovými programy, které spolupracují, se nazývá [zapouzdřená složitost](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Tento přístup usnadnil bezproblémové provedení [sloučení](/roadmap/merge), usnadňuje údržbu a vývoj klientského softwaru a umožňuje opětovné použití jednotlivých klientů, například v [ekosystému druhé vrstvy](/layer-2/). + +![Propojené exekuční a konsensuální klienty](./eth1eth2client.png) +Zjednodušené schéma propojeného exekučního a konsensuálního klienta. + +### Diverzita klientů {#client-diversity} + +[Exekuční klienti](/developers/docs/nodes-and-clients/#execution-clients) i [konsensuální klienti](/developers/docs/nodes-and-clients/#consensus-clients) existují v různých programovacích jazycích a jsou vyvíjeni různými týmy. + +Více implementací klientů může posílit síť tím, že se sníží její závislost na jediné kódové základně. Ideálním cílem je dosáhnout rozmanitosti, aniž by síti dominoval jediný klient, čímž se eliminuje potenciální jediný bod selhání. +Rozmanitost jazyků také láká širší komunitu vývojářů a umožňuje jim vytvářet integrace v jimi preferovaném jazyce. + +Zjistěte více o [rozmanitosti klientů](/developers/docs/nodes-and-clients/client-diversity/). + +Společným rysem těchto implementací je, že se všechny řídí jedinou specifikací. Specifikace určují, jak funguje síť Ethereum a její blockchain. Každý technický detail je definován a specifikace lze nalézt jako: + +- Původně [Žlutá kniha Etherea](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Specifikace exekuce](https://github.com/ethereum/execution-specs/) +- [Specifikace konsensu](https://github.com/ethereum/consensus-specs) +- [EIP](https://eips.ethereum.org/) implementované v různých [vylepšeních sítě](/ethereum-forks/) + +### Sledování uzlů v síti {#network-overview} + +Několik trackerů nabízí přehled uzlů v síti Ethereum v reálném čase. Všimněte si, že vzhledem k povaze decentralizovaných sítí mohou tyto crawlery poskytovat pouze omezený pohled na síť a mohou hlásit různé výsledky. + +- [Mapa uzlů](https://etherscan.io/nodetracker) od Etherscanu +- [Ethernodes](https://ethernodes.org/) od Bitfly +- [Nodewatch](https://www.nodewatch.io/) od Chainsafe, prochází konsensuální uzly +- [Monitoreth](https://monitoreth.io/) – od MigaLabs, distribuovaný nástroj pro monitorování sítě +- [Weekly Network Health Reports](https://probelab.io) – od ProbeLab, s využitím crawleru [Nebula](https://github.com/dennis-tra/nebula) a dalších nástrojů + +## Typy uzlů {#node-types} + +Chcete-li si [spustit vlastní uzel](/developers/docs/nodes-and-clients/run-a-node/), měli byste pochopit, že existují různé typy uzlů, které spotřebovávají data odlišně. Klienti mohou provozovat tři různé typy uzlů: lehké, plné a archivní. Existují také možnosti různých synchronizačních strategií, které umožňují rychlejší synchronizaci. Synchronizace se vztahuje k tomu, jak rychle dokáže získat nejaktuálnější informace o stavu Etherea. + +### Plný uzel {#full-node} + +Plné uzly provádějí validaci blockchainu blok po bloku, včetně stahování a ověřování těla bloku a stavových dat pro každý blok. Existují různé třídy plných uzlů – některé začínají od genesis bloku a ověřují každý jednotlivý blok v celé historii blockchainu. Jiné začínají ověřování od novějšího bloku, který považují za platný (např. 'snap sync' klienta Geth). Bez ohledu na to, kde ověření začíná, plné uzly uchovávají pouze lokální kopii relativně nedávných dat (typicky posledních 128 bloků), což umožňuje smazat starší data a ušetřit tak místo na disku. Starší data mohou být v případě potřeby znovu vygenerována. + +- Ukládá kompletní data blockchainu (ačkoli jsou pravidelně prořezávána, takže plný uzel neukládá všechna stavová data až po genesis blok) +- Účastní se validace bloků, ověřuje všechny bloky a stavy. +- Všechny stavy mohou být buď načteny z lokálního úložiště, nebo znovu vygenerovány ze 'snímků' plným uzlem. +- Slouží síti a poskytuje data na vyžádání. + +### Archivní uzel {#archive-node} + +Archivní uzly jsou plné uzly, které ověřují každý blok od genesis bloku a nikdy nemažou žádná stažená data. + +- Ukládá vše, co je uchováváno v plném uzlu, a vytváří archiv historických stavů. Je zapotřebí, pokud chcete zjistit například zůstatek na účtu v bloku č. 4 000 000 nebo jednoduše a spolehlivě otestovat vlastní sadu transakcí bez jejich ověřování pomocí trasování. +- Tato data představují jednotky terabajtů, což činí archivní uzly méně atraktivními pro běžné uživatele, ale mohou být užitečné pro služby jako jsou prohlížeče bloků, poskytovatelé peněženek a analytika řetězce. + +Synchronizace klientů v jakémkoli jiném režimu než archivním bude mít za následek prořezaná data blockchainu. To znamená, že neexistuje archiv všech historických stavů, ale plný uzel je schopen je na vyžádání vytvořit. + +Zjistěte více o [archivních uzlech](/developers/docs/nodes-and-clients/archive-nodes). + +### Lehký uzel {#light-node} + +Místo stahování každého bloku stahují lehké uzly pouze hlavičky bloků. Tyto hlavičky obsahují souhrnné informace o obsahu bloků. Jakékoli další informace, které lehký uzel potřebuje, si vyžádá od plného uzlu. Lehký uzel pak může nezávisle ověřit data, která obdrží, oproti kořenům stavu v hlavičkách bloků. Lehké uzly umožňují uživatelům účastnit se sítě Ethereum bez výkonného hardwaru nebo vysoké šířky pásma potřebné k provozu plných uzlů. Časem by lehké uzly mohly běžet na mobilních telefonech nebo vestavěných zařízeních. Lehké uzly se neúčastní konsensu (tzn. nemohou být validátory), ale mohou přistupovat k blockchainu Etherea se stejnou funkčností a bezpečnostními zárukami jako plný uzel. + +Lehcí klienti jsou oblastí aktivního vývoje Etherea a očekáváme, že brzy uvidíme nové lehké klienty pro konsensuální a exekuční vrstvu. +Existují také potenciální cesty k poskytování dat lehkých klientů přes [gossip síť](https://www.ethportal.net/). To je výhodné, protože gossip síť by mohla podporovat síť lehkých uzlů, aniž by vyžadovala plné uzly pro obsluhu požadavků. + +Ethereum zatím nepodporuje velkou populaci lehkých uzlů, ale podpora lehkých uzlů je oblast, u které se v blízké budoucnosti očekává rychlý rozvoj. Zejména klienti jako [Nimbus](https://nimbus.team/), [Helios](https://github.com/a16z/helios) a [LodeStar](https://lodestar.chainsafe.io/) se v současné době silně zaměřují na lehké uzly. + +## Proč bych měl provozovat uzel sítě Ethereum? {#why-should-i-run-an-ethereum-node} + +Provozování uzlu vám umožňuje přímo, bez nutnosti důvěry a soukromě používat Ethereum a zároveň podporovat síť tím, že ji udržujete robustnější a decentralizovanější. + +### Výhody pro vás {#benefits-to-you} + +Provozování vlastního uzlu vám umožňuje používat Ethereum soukromým, soběstačným způsobem bez nutnosti důvěry. Nemusíte důvěřovat síti, protože si data můžete sami ověřit pomocí svého klienta. „Nedůvěřuj, ověřuj“ je populární mantra blockchainu. + +- Váš uzel sám ověřuje všechny transakce a bloky podle pravidel konsensu. To znamená, že se nemusíte spoléhat na žádné jiné uzly v síti ani jim plně důvěřovat. +- S vlastním uzlem můžete používat peněženku Ethereum. Aplikace dApps můžete používat bezpečněji a soukroměji, protože nebudete muset prozrazovat své adresy a zůstatky zprostředkovatelům. Vše lze zkontrolovat pomocí vlastního klienta. [MetaMask](https://metamask.io), [Frame](https://frame.sh/) a [mnoho dalších peněženek](/wallets/find-wallet/) nabízejí import RPC, což jim umožňuje používat váš uzel. +- Můžete spouštět a sami hostovat další služby, které závisí na datech z Etherea. Může se jednat například o validátor Beacon Chain, software jako druhá vrstva, infrastrukturu, prohlížeče bloků, zpracovatele plateb atd. +- Můžete poskytovat vlastní [koncové body RPC](/developers/docs/apis/json-rpc/). Tyto koncové body můžete dokonce veřejně nabídnout komunitě, abyste jim pomohli vyhnout se velkým centralizovaným poskytovatelům. +- K uzlu se můžete připojit pomocí **meziprocesové komunikace (IPC)** nebo přepsat uzel tak, aby se váš program načetl jako plugin. To zaručuje nízkou latenci, což hodně pomáhá, např. při zpracování velkého množství dat pomocí knihoven web3 nebo když potřebujete co nejrychleji nahradit své transakce (tj. frontrunning). +- Můžete přímo stakovat ETH, abyste zabezpečili síť a získali odměny. Pro začátek se podívejte na [sólo stakování](/staking/solo/). + +![Jak přistupujete k Ethereu prostřednictvím své aplikace a uzlů](./nodes.png) + +### Výhody sítě {#network-benefits} + +Rozmanitá sada uzlů je důležitá pro zdraví, bezpečnost a provozní odolnost Etherea. + +- Plné uzly vynucují pravidla konsensu, takže je nelze oklamat, aby přijímaly bloky, které je nedodržují. To poskytuje dodatečnou bezpečnost v síti, protože pokud by všechny uzly byly lehké uzly, které neprovádějí úplné ověření, mohli by validátoři na síť zaútočit. +- V případě útoku, který překoná kryptoekonomickou obranu [důkazu podílem](/developers/docs/consensus-mechanisms/pos/#what-is-pos), mohou plné uzly provést sociální obnovu tím, že se rozhodnou následovat poctivý řetězec. +- Více uzlů v síti vede k rozmanitější a robustnější síti, což je konečným cílem decentralizace, která umožňuje systém odolný vůči cenzuře a spolehlivý. +- Plné uzly poskytují přístup k datům blockchainu pro lehké klienty, kteří na nich závisí. Lehké uzly neukládají celý blockchain, místo toho ověřují data prostřednictvím [kořenů stavu v hlavičkách bloků](/developers/docs/blocks/#block-anatomy). V případě potřeby si mohou od plných uzlů vyžádat více informací. + +Pokud provozujete plný uzel, prospívá to celé síti Ethereum, i když neprovozujete validátor. + +## Provozování vlastního uzlu {#running-your-own-node} + +Máte zájem o spuštění vlastního klienta Etherea? + +Pro začátečnický úvod navštivte naši stránku [spustit uzel](/run-a-node) a dozvíte se více. + +Pokud jste technicky zdatnější uživatel, ponořte se do podrobností a možností, jak [spustit vlastní uzel](/developers/docs/nodes-and-clients/run-a-node/). + +## Alternativy {#alternatives} + +Nastavení vlastního uzlu vás může stát čas a zdroje, ale ne vždy potřebujete provozovat vlastní instanci. V tomto případě můžete použít poskytovatele API třetí strany. Přehled použití těchto služeb najdete na stránce [uzly jako služba](/developers/docs/nodes-and-clients/nodes-as-a-service/). + +Pokud někdo ve vaší komunitě provozuje uzel Etherea s veřejným API, můžete své peněženky nasměrovat na komunitní uzel přes vlastní RPC a získat tak více soukromí než u nějaké náhodné důvěryhodné třetí strany. + +Na druhou stranu, pokud provozujete klienta, můžete jej sdílet se svými přáteli, kteří by jej mohli potřebovat. + +## Exekuční klienti {#execution-clients} + +Komunita Etherea udržuje několik open-source exekučních klientů (dříve známých jako „klienti Eth1“ nebo jen „klienti Etherea“), vyvinutých různými týmy v různých programovacích jazycích. Díky tomu je síť silnější a [rozmanitější](/developers/docs/nodes-and-clients/client-diversity/). Ideálním cílem je dosáhnout rozmanitosti, aniž by síti dominoval jediný klient, čímž se omezí jednotlivé body selhání. + +Tato tabulka shrnuje různé klienty. Všichni procházejí [testy klientů](https://github.com/ethereum/tests) a jsou aktivně udržováni, aby byli aktuální s vylepšeními sítě. + +| Klient | Jazyk | Operační systémy | Sítě | Strategie synchronizace | Prořezávání stavu | +| ------------------------------------------------------------------------------------------- | ------------------------ | --------------------- | ----------------------- | -------------------------------------------------------------------------------- | ------------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync), [Úplná](#full-sync) | Archivní, Prořezaný | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync) (bez obsluhy), Rychlá, [Úplná](#full-sync) | Archivní, Prořezaný | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Snap](#snap-sync), [Rychlá](#fast-sync), [Úplná](#full-sync) | Archivní, Prořezaný | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Úplná](#full-sync) | Archivní, Prořezaný | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Mainnet, Sepolia, Hoodi | [Úplná](#full-sync) | Archivní, Prořezaný | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(beta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Hoodi | [Úplná](#full-sync) | Prořezaný | + +Více informací o podporovaných sítích naleznete na stránce [sítě Etherea](/developers/docs/networks/). + +Každý klient má jedinečné případy použití a výhody, takže byste si měli vybrat podle svých vlastních preferencí. Rozmanitost umožňuje, aby se implementace zaměřovaly na různé funkce a skupiny uživatelů. Klienta si můžete vybrat na základě funkcí, podpory, programovacího jazyka nebo licencí. + +### Besu {#besu} + +Hyperledger Besu je klient Etherea podnikové třídy pro veřejné sítě a sítě s oprávněními. Provozuje všechny funkce Ethereum Mainnet, od trasování po GraphQL, má rozsáhlé monitorování a je podporován společností ConsenSys, a to jak v otevřených komunitních kanálech, tak prostřednictvím komerčních SLA pro podniky. Je napsán v jazyce Java a licencován pod Apache 2.0. + +Rozsáhlá [dokumentace](https://besu.hyperledger.org/en/stable/) klienta Besu vás provede všemi podrobnostmi o jeho funkcích a nastaveních. + +### Erigon {#erigon} + +Erigon, dříve známý jako Turbo-Geth, začal jako větev Go Ethereum zaměřená na rychlost a efektivitu využití diskového prostoru. Erigon je kompletně přepracovaná implementace Etherea, v současné době napsaná v jazyce Go, ale s implementacemi v dalších jazycích ve vývoji. Cílem Erigonu je poskytnout rychlejší, modulárnější a optimalizovanější implementaci Etherea. Dokáže provést plnou synchronizaci archivního uzlu s využitím přibližně 2 TB místa na disku za méně než 3 dny. + +### Go Ethereum {#geth} + +Go Ethereum (zkráceně Geth) je jednou z původních implementací protokolu Ethereum. V současné době je to nejrozšířenější klient s největší uživatelskou základnou a rozmanitostí nástrojů pro uživatele a vývojáře. Je napsán v jazyce Go, je plně open-source a licencován pod GNU LGPL v3. + +Zjistěte více o Gethu v jeho [dokumentaci](https://geth.ethereum.org/docs/). + +### Nethermind {#nethermind} + +Nethermind je implementace Etherea vytvořená pomocí technologického stacku C# .NET, licencovaná pod LGPL-3.0 a běžící na všech hlavních platformách včetně ARM. Nabízí skvělý výkon s: + +- optimalizovaným virtuálním strojem +- přístupem ke stavu +- sítěmi a bohatými funkcemi, jako jsou dashboardy Prometheus/Grafana, podpora podnikového protokolování seq, trasování JSON-RPC a analytické pluginy. + +Nethermind má také [podrobnou dokumentaci](https://docs.nethermind.io), silnou vývojářskou podporu, online komunitu a podporu 24/7 dostupnou pro prémiové uživatele. + +### Reth {#reth} + +Reth (zkratka pro Rust Ethereum) je implementace plného uzlu Etherea, která je zaměřena na uživatelskou přívětivost, vysokou modularitu, rychlost a efektivitu. Reth byl původně vytvořen a poháněn společností Paradigm a je licencován pod licencemi Apache a MIT. + +Reth je připraven pro produkční nasazení a je vhodný pro použití v kriticky důležitých prostředích, jako je stakování nebo služby s vysokou dostupností. Dobře si vede v případech použití, kde je vyžadován vysoký výkon s velkými rezervami, jako jsou RPC, MEV, indexování, simulace a P2P aktivity. + +Zjistěte více v [Reth Book](https://reth.rs/) nebo v [repozitáři Reth na GitHubu](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth). + +### Ve vývoji {#execution-in-development} + +Tito klienti jsou stále v raných fázích vývoje a zatím se nedoporučují pro produkční použití. + +#### EthereumJS {#ethereumjs} + +Exekuční klient EthereumJS (EthereumJS) je napsán v TypeScriptu a skládá se z řady balíčků, včetně základních primitiv Etherea reprezentovaných třídami Block, Transaction a Merkle-Patricia Trie a základních komponent klienta, včetně implementace Ethereum Virtual Machine (EVM), třídy blockchainu a síťového stacku DevP2P. + +Zjistěte více v jeho [dokumentaci](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) + +## Konsensuální klienti {#consensus-clients} + +Existuje několik konsensuálních klientů (dříve známých jako klienti „Eth2“), kteří podporují [vylepšení konsensu](/roadmap/beacon-chain/). Jsou zodpovědní za veškerou logiku související s konsensem, včetně algoritmu volby větve, zpracování atestací a správy odměn a penalizací [důkazu podílem](/developers/docs/consensus-mechanisms/pos). + +| Klient | Jazyk | Operační systémy | Sítě | +| ------------------------------------------------------------- | ---------- | --------------------- | ----------------------------------------------------- | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Hoodi, Pyrmont, Sepolia a další | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia a další | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia a další | +| [Prysm](https://prysm.offchainlabs.com/docs/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Hoodi, Pyrmont, Sepolia a další | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Hoodi, Sepolia a další | +| [Grandine](https://docs.grandine.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Hoodi, Sepolia a další | + +### Lighthouse {#lighthouse} + +Lighthouse je implementace konsensuálního klienta napsaná v Rustu pod licencí Apache-2.0. Je udržován společností Sigma Prime a je stabilní a připravený k produkčnímu nasazení od genesis bloku Beacon Chainu. Spoléhají na něj různé podniky, stakovací pooly a jednotlivci. Jeho cílem je být bezpečný, výkonný a interoperabilní v široké škále prostředí, od stolních PC až po sofistikovaná automatizovaná nasazení. + +Dokumentaci naleznete v [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) + +### Lodestar {#lodestar} + +Lodestar je produkčně připravená implementace konsensuálního klienta napsaná v Typescriptu pod licencí LGPL-3.0. Je udržován společností ChainSafe Systems a je nejnovějším z konsensuálních klientů pro sólo stakery, vývojáře a výzkumníky. Lodestar se skládá z beacon uzlu a klienta validátoru poháněného implementacemi protokolů Etherea v JavaScriptu. Lodestar si klade za cíl zlepšit použitelnost Etherea pomocí lehkých klientů, rozšířit dostupnost pro větší skupinu vývojářů a dále přispět k rozmanitosti ekosystému. + +Více informací naleznete na [webu Lodestar](https://lodestar.chainsafe.io/) + +### Nimbus {#nimbus} + +Nimbus je implementace konsensuálního klienta napsaná v jazyce Nim pod licencí Apache-2.0. Je to produkčně připravený klient, který používají sólo stakeři a stakovací pooly. Nimbus je navržen pro efektivní využití zdrojů, což usnadňuje jeho provoz na zařízeních s omezenými zdroji i na podnikové infrastruktuře se stejnou lehkostí, aniž by byla ohrožena stabilita nebo výkon odměn. Menší náročnost na zdroje znamená, že klient má větší bezpečnostní rezervu, když je síť pod tlakem. + +Zjistěte více v [dokumentaci Nimbus](https://nimbus.guide/) + +### Prysm {#prysm} + +Prysm je plně funkční open-source konsensuální klient napsaný v Go pod licencí GPL-3.0. Obsahuje volitelné webové uživatelské rozhraní a upřednostňuje uživatelský zážitek, dokumentaci a konfigurovatelnost jak pro domácí stakery, tak pro institucionální uživatele. + +Navštivte [dokumentaci Prysm](https://prysm.offchainlabs.com/docs/) a dozvíte se více. + +### Teku {#teku} + +Teku je jedním z původních klientů z doby genesis Beacon Chainu. Kromě obvyklých cílů (bezpečnost, robustnost, stabilita, použitelnost, výkon) se Teku specificky snaží plně vyhovět všem různým standardům pro konsensuální klienty. + +Teku nabízí velmi flexibilní možnosti nasazení. Beacon uzel a klient validátoru mohou být spuštěny společně jako jeden proces, což je mimořádně pohodlné pro sólo stakery, nebo mohou být uzly spuštěny samostatně pro sofistikované stakovací operace. Kromě toho je Teku plně interoperabilní s [Web3Signer](https://github.com/ConsenSys/web3signer/) pro zabezpečení podpisových klíčů a ochranu proti slashingu. + +Teku je napsán v jazyce Java a licencován pod Apache 2.0. Je vyvíjen týmem Protocols v ConsenSys, který je také zodpovědný za Besu a Web3Signer. Zjistěte více v [dokumentaci Teku](https://docs.teku.consensys.net/en/latest/). + +### Grandine {#grandine} + +Grandine je implementace konsensuálního klienta, napsaná v Rustu pod licencí GPL-3.0. Je udržován týmem Grandine Core a je rychlý, výkonný a lehký. Vyhovuje široké škále stakerů od sólo stakerů běžících na zařízeních s nízkými zdroji, jako je Raspberry Pi, až po velké institucionální stakery provozující desítky tisíc validátorů. + +Dokumentaci naleznete v [Grandine Book](https://docs.grandine.io/) + +## Režimy synchronizace {#sync-modes} + +Aby mohl klient Etherea sledovat a ověřovat aktuální data v síti, musí se synchronizovat s nejnovějším stavem sítě. To se provádí stahováním dat od peerů, kryptografickým ověřováním jejich integrity a budováním lokální databáze blockchainu. + +Režimy synchronizace představují různé přístupy k tomuto procesu s různými kompromisy. Klienti se také liší v implementaci synchronizačních algoritmů. Vždy se obraťte na oficiální dokumentaci vámi zvoleného klienta pro specifika implementace. + +### Režimy synchronizace exekuční vrstvy {#execution-layer-sync-modes} + +Exekuční vrstva může být spuštěna v různých režimech, aby vyhovovala různým případům použití, od opětovného provedení světového stavu blockchainu až po synchronizaci pouze s čelem řetězce z důvěryhodného checkpointu. + +#### Úplná synchronizace {#full-sync} + +Úplná synchronizace stahuje všechny bloky (včetně hlaviček a těl bloků) a postupně regeneruje stav blockchainu prováděním každého bloku od genesis bloku. + +- Minimalizuje důvěru a nabízí nejvyšší bezpečnost ověřováním každé transakce. +- S rostoucím počtem transakcí může zpracování všech transakcí trvat dny až týdny. + +[Archivní uzly](#archive-node) provádějí úplnou synchronizaci, aby vytvořily (a uchovaly) kompletní historii změn stavu provedených každou transakcí v každém bloku. + +#### Rychlá synchronizace {#fast-sync} + +Stejně jako úplná synchronizace, i rychlá synchronizace stahuje všechny bloky (včetně hlaviček, transakcí a potvrzení). Místo opětovného zpracování historických transakcí se však rychlá synchronizace spoléhá na potvrzení, dokud nedosáhne nedávného čela, kdy přejde na import a zpracování bloků, aby poskytla plný uzel. + +- Strategie rychlé synchronizace. +- Snižuje nároky na zpracování ve prospěch využití šířky pásma. + +#### Snap synchronizace {#snap-sync} + +Snap synchronizace také ověřují řetězec blok po bloku. Místo toho, aby začala od genesis bloku, snap synchronizace začíná od novějšího „důvěryhodného“ checkpointu, o kterém je známo, že je součástí skutečného blockchainu. Uzel ukládá periodické checkpointy a zároveň maže data starší než určitý věk. Tyto snímky se používají k regeneraci stavových dat podle potřeby, místo aby se ukládala navždy. + +- Nejrychlejší strategie synchronizace, v současnosti výchozí v Ethereum Mainnet. +- Šetří velké množství místa na disku a šířky pásma sítě bez obětování bezpečnosti. + +[Více o snap synchronizaci](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). + +#### Lehká synchronizace {#light-sync} + +Režim lehkého klienta stahuje všechny hlavičky bloků, data bloků a náhodně některé ověřuje. Synchronizuje pouze čelo řetězce z důvěryhodného checkpointu. + +- Získává pouze nejnovější stav a spoléhá na důvěru ve vývojáře a mechanismus konsensu. +- Klient je připraven k použití s aktuálním stavem sítě během několika minut. + +**Pozn.** Lehká synchronizace zatím nefunguje s Ethereem proof-of-stake – nové verze lehké synchronizace by měly být brzy k dispozici! + +[Více o lehkých klientech](/developers/docs/nodes-and-clients/light-clients/) + +### Režimy synchronizace konsensuální vrstvy {#consensus-layer-sync-modes} + +#### Optimistická synchronizace {#optimistic-sync} + +Optimistická synchronizace je strategie synchronizace po sloučení, navržená tak, aby byla volitelná a zpětně kompatibilní, což umožňuje exekučním uzlům synchronizovat se zavedenými metodami. Exekuční engine může _optimisticky_ importovat beacon bloky, aniž by je plně ověřoval, najít nejnovější čelo a poté začít synchronizovat řetězec výše uvedenými metodami. Poté, co se exekuční klient dostane do synchronizace, bude informovat konsensuálního klienta o platnosti transakcí v Beacon Chainu. + +[Více o optimistické synchronizaci](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### Synchronizace z checkpointu {#checkpoint-sync} + +Synchronizace z checkpointu, známá také jako synchronizace slabé subjektivity, vytváří vynikající uživatelský zážitek pro synchronizaci Beacon uzlu. Je založena na předpokladech [slabé subjektivity](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/), což umožňuje synchronizaci Beacon Chainu z nedávného checkpointu slabé subjektivity místo z genesis bloku. Synchronizace z checkpointu výrazně zrychlují počáteční dobu synchronizace s podobnými předpoklady důvěry jako synchronizace z [genesis bloku](/glossary/#genesis-block). + +V praxi to znamená, že se váš uzel připojí ke vzdálené službě, aby si stáhl nedávné finalizované stavy a od tohoto bodu pokračoval v ověřování dat. Třetí strana poskytující data je důvěryhodná a měla by být pečlivě vybrána. + +Více o [synchronizaci z checkpointu](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) + +## Další čtení {#further-reading} + +- [Ethereum 101 – Část 2 – Porozumění uzlům](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes, 13. února 2019_ +- [Provozování plných uzlů Ethereum: Příručka pro sotva motivované](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 7. listopadu 2019_ + +## Související témata {#related-topics} + +- [Bloky](/developers/docs/blocks/) +- [Sítě](/developers/docs/networks/) + +## Související návody {#related-tutorials} + +- [Proměňte své Raspberry Pi 4 na uzel validátoru pouhým flashnutím microSD karty – Instalační příručka](/developers/tutorials/run-node-raspberry-pi/) _– Flashněte své Raspberry Pi 4, zapojte ethernetový kabel, připojte SSD disk a zapněte zařízení, abyste z Raspberry Pi 4 udělali plný uzel Etherea provozující exekuční vrstvu (Mainnet) a/nebo konsensuální vrstvu (Beacon Chain / validátor)._ diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/light-clients/index.md new file mode 100644 index 00000000000..53ac5c6fc97 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/light-clients/index.md @@ -0,0 +1,61 @@ +--- +title: "Jednoduché klienty" +description: "Úvod do lehkých klientů Etherea." +lang: cs +--- + +Provozování plného uzlu je způsob interakce s Ethereem, který nevyžaduje důvěru, je soukromý, decentralizovaný a odolný vůči cenzuře. S plným uzlem si uchováváte vlastní kopii blockchainu, na kterou se můžete okamžitě dotazovat, a získáte přímý přístup do peer-to-peer sítě Etherea. Provozování plného uzlu však vyžaduje značné množství paměti, úložiště a CPU. To znamená, že není pro každého proveditelné, aby provozoval svůj vlastní uzel. V plánu Etherea existuje několik řešení, včetně bezstavovosti, ale od jejich implementace nás dělí několik let. Krátkodobým řešením je vyměnit některé výhody provozování plného uzlu za velké zlepšení výkonu, které umožňuje provozovat uzly s velmi nízkými hardwarovými nároky. Uzly, které dělají tento kompromis, jsou známé jako lehké uzly. + +## Co je to lehký klient {#what-is-a-light-client} + +Lehký uzel je uzel, který provozuje software lehkého klienta. Místo toho, aby si uchovávaly místní kopie dat blockchainu a nezávisle ověřovaly všechny změny, požadují potřebná data od poskytovatele. Poskytovatelem může být přímé připojení k plnému uzlu nebo centralizovaný RPC server. Data jsou poté ověřena lehkým uzlem, což mu umožňuje držet krok s čelem řetězce. Lehký uzel zpracovává pouze hlavičky bloků a jen příležitostně stahuje skutečný obsah bloků. Uzly se mohou lišit ve své „lehkosti“ v závislosti na kombinacích softwaru lehkých a plných klientů, které provozují. Nejlehčí konfigurací by bylo například spuštění lehkého exekučního klienta a lehkého konsensuálního klienta. Je také pravděpodobné, že mnoho uzlů se rozhodne provozovat lehké konsensuální klienty s plnými exekučními klienty, nebo naopak. + +## Jak fungují lehcí klienti? {#how-do-light-clients-work} + +Když Ethereum začalo používat mechanismus konsensu založený na důkazu podílem, byla zavedena nová infrastruktura speciálně pro podporu lehkých klientů. Funguje to tak, že se každých 1,1 dne náhodně vybere podmnožina 512 validátorů, kteří fungují jako **synchronizační výbor**. Synchronizační výbor podepisuje hlavičku posledních bloků. Každá hlavička bloku obsahuje agregovaný podpis validátorů v synchronizačním výboru a „bitové pole“, které ukazuje, kteří validátoři podepsali a kteří ne. Každá hlavička také obsahuje seznam validátorů, od kterých se očekává, že se zúčastní podepisování dalšího bloku. To znamená, že lehký klient může rychle zjistit, že synchronizační výbor podepsal data, která obdrží, a může také zkontrolovat, že synchronizační výbor je ten pravý, porovnáním toho, který obdrží, s tím, který mu bylo řečeno očekávat v předchozím bloku. Tímto způsobem si může lehký klient udržovat aktuální znalosti o nejnovějším bloku Etherea, aniž by stahoval samotný blok, ale pouze hlavičku, která obsahuje souhrnné informace. + +Na exekuční vrstvě neexistuje jednotná specifikace pro lehkého exekučního klienta. Rozsah lehkého exekučního klienta se může lišit od „lehkého režimu“ plného exekučního klienta, který má všechny funkce EVM a síťové funkce plného uzlu, ale ověřuje pouze hlavičky bloků bez stahování souvisejících dat, nebo to může být více osekaný klient, který se silně spoléhá na předávání požadavků poskytovateli RPC pro interakci s Ethereem. + +## Proč jsou lehcí klienti důležití? {#why-are-light-clients-important} + +Lehcí klienti jsou důležití, protože umožňují uživatelům ověřovat příchozí data, místo aby slepě důvěřovali, že jejich poskytovatel dat je správný a poctivý, a přitom využívají jen malý zlomek výpočetních zdrojů plného uzlu. Data, která lehcí klienti obdrží, lze zkontrolovat vůči hlavičkám bloků, o kterých vědí, že byly podepsány alespoň 2/3 náhodné sady 512 validátorů Etherea. To je velmi silný důkaz, že data jsou správná. + +Lehký klient využívá jen malé množství výpočetního výkonu, paměti a úložiště, takže ho lze spustit na mobilním telefonu, vložit do aplikace nebo jako součást prohlížeče. Lehcí klienti jsou způsob, jak učinit přístup k Ethereu s minimalizovanou důvěrou stejně bezproblémovým jako důvěřování poskytovateli třetí strany. + +Uveďme si jednoduchý příklad. Představte si, že si chcete zkontrolovat zůstatek na účtu. K tomu musíte odeslat požadavek na uzel Etherea. Tento uzel zkontroluje svou místní kopii stavu Etherea pro váš zůstatek a vrátí vám ho. Pokud nemáte přímý přístup k uzlu, existují centralizovaní operátoři, kteří tato data poskytují jako službu. Můžete jim poslat požadavek, oni zkontrolují svůj uzel a pošlou vám výsledek zpět. Problém je v tom, že pak musíte důvěřovat poskytovateli, že vám poskytuje správné informace. Nikdy si nemůžete být jisti, že jsou informace správné, pokud si je nemůžete sami ověřit. + +Lehký klient tento problém řeší. Stále si vyžadujete data od externího poskytovatele, ale když data obdržíte zpět, přijdou s důkazem, který si váš lehký uzel může zkontrolovat vůči informacím, které obdržel v hlavičce bloku. To znamená, že správnost vašich dat ověřuje Ethereum namísto nějakého důvěryhodného operátora. + +## Jaké inovace lehcí klienti umožňují? {#what-innovations-do-light-clients-enable} + +Hlavním přínosem lehkých klientů je umožnit více lidem nezávislý přístup k Ethereu se zanedbatelnými hardwarovými nároky a minimální závislostí na třetích stranách. To je dobré pro uživatele, protože si mohou ověřit svá vlastní data, a je to dobré pro síť, protože to zvyšuje počet a rozmanitost uzlů, které ověřují řetězec. + +Schopnost provozovat uzly Etherea na zařízeních s velmi malým úložištěm, pamětí a výpočetním výkonem je jednou z hlavních oblastí inovací, které lehcí klienti odemykají. Zatímco dnes uzly Etherea vyžadují mnoho výpočetních zdrojů, lehcí klienti by mohli být vloženi do prohlížečů, spuštěni na mobilních telefonech a možná i na menších zařízeních, jako jsou chytré hodinky. To znamená, že peněženky Ethereum s vestavěnými klienty by mohly běžet na mobilním telefonu. To znamená, že mobilní peněženky by mohly být mnohem více decentralizované, protože by nemusely důvěřovat centralizovaným poskytovatelům dat pro svá data. + +Rozšířením toho je podpora zařízení **internetu věcí (IoT)**. Lehký klient by mohl být použit k rychlému prokázání vlastnictví nějakého zůstatku tokenu nebo NFT, se všemi bezpečnostními zárukami poskytovanými synchronizačními výbory, což by vyvolalo nějakou akci v síti IoT. Představte si [půjčovnu kol](https://youtu.be/ZHNrAXf3RDE?t=929), která používá aplikaci s vestavěným lehkým klientem k rychlému ověření, že vlastníte NFT půjčovny, a pokud ano, odemkne vám kolo, na kterém můžete odjet! + +Z lehkých klientů by také těžily rollupy Etherea. Jedním z velkých problémů pro rollupy byly hackerské útoky zaměřené na přemostění, která umožňují převod prostředků z hlavní sítě Etherea na rollup. Jednou ze zranitelností jsou orákula, která rollupy používají k detekci, že uživatel provedl vklad na přemostění. Pokud orákulum dodá špatná data, mohlo by přimět rollup k tomu, aby si myslel, že došlo k vkladu na přemostění, a nesprávně uvolnil prostředky. Lehký klient zabudovaný v rollupu by mohl být použit k ochraně proti poškozeným orákulům, protože vklad do přemostění by mohl přijít s důkazem, který si rollup může ověřit před uvolněním jakýchkoli tokenů. Stejný koncept by se dal použít i na jiná meziřetězcová přemostění. + +Lehké klienty by bylo možné použít také k vylepšení peněženek Ethereum. Místo důvěřování datům poskytovaným poskytovatelem RPC by si vaše peněženka mohla přímo ověřit data, která vám jsou předkládána, pomocí vestavěného lehkého klienta. To by zvýšilo bezpečnost vaší peněženky. Pokud by byl váš poskytovatel RPC nečestný a poskytl vám nesprávná data, vestavěný lehký klient by vás na to mohl upozornit! + +## Jaký je současný stav vývoje lehkých klientů? {#current-state-of-development} + +Ve vývoji je několik lehkých klientů, včetně exekučních, konsensuálních a kombinovaných exekučních/konsensuálních lehkých klientů. Toto jsou implementace lehkých klientů, o kterých víme v době psaní této stránky: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): konsensuální lehký klient v TypeScriptu +- [Helios](https://github.com/a16z/helios): kombinovaný exekuční a konsensuální lehký klient v Rustu +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): lehký režim pro exekučního klienta (ve vývoji) v Go +- [Nimbus](https://nimbus.guide/el-light-client.html): konsensuální lehký klient v Nimu + +Podle našich informací žádný z nich zatím není považován za připravený pro produkční nasazení. + +Probíhá také mnoho práce na zlepšení způsobů, jakými mohou lehcí klienti přistupovat k datům Etherea. V současné době se lehcí klienti spoléhají na RPC požadavky na plné uzly pomocí modelu klient/server, ale v budoucnu by data mohla být požadována decentralizovanějším způsobem pomocí vyhrazené sítě, jako je [Portal Network](https://www.ethportal.net/), která by mohla data lehkým klientům poskytovat pomocí protokolu peer-to-peer gossip. + +Další položky [plánu](/roadmap/), jako jsou [Verkle stromy](/roadmap/verkle-trees/) a [bezstavovost](/roadmap/statelessness/), nakonec přinesou bezpečnostní záruky lehkých klientů na úroveň plných klientů. + +## Další čtení {#further-reading} + +- [Zsolt Felfodhi o lehkých klientech Geth](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Etan Kissling o síťování lehkých klientů](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Etan Kissling o lehkých klientech po Sloučení](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam: Trnitá cesta k funkčním lehkým klientům](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/node-architecture/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/node-architecture/index.md new file mode 100644 index 00000000000..26199ed95d3 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/node-architecture/index.md @@ -0,0 +1,59 @@ +--- +title: "Architektura uzlů" +description: "Úvod do organizace uzlů sítě Ethereum." +lang: cs +--- + +Uzel sítě Ethereum se skládá ze dvou klientů: [exekučního klienta](/developers/docs/nodes-and-clients/#execution-clients) a [konsensuálního klienta](/developers/docs/nodes-and-clients/#consensus-clients). Aby mohl uzel navrhnout nový blok, musí na něm také běžet [klient validátoru](#validators). + +Když Ethereum používalo [důkaz prací](/developers/docs/consensus-mechanisms/pow/), stačil k provozování plného uzlu sítě Ethereum exekuční klient. Od zavedení [důkazu podílem](/developers/docs/consensus-mechanisms/pow/) se však musí exekuční klient používat společně s dalším softwarem, který se nazývá [konsensuální klient](/developers/docs/nodes-and-clients/#consensus-clients). + +Níže uvedený diagram znázorňuje vztah mezi dvěma klienty sítě Ethereum. Oba klienti se připojují ke svým vlastním sítím peer-to-peer (P2P). Jsou zapotřebí oddělené P2P sítě, protože exekuční klienti si přes svou P2P síť vyměňují transakce, což jim umožňuje spravovat jejich lokální transakční pool, zatímco konsensuální klienti si přes svou P2P síť vyměňují bloky, což umožňuje konsensus a růst řetězce. + +![](node-architecture-text-background.png) + +_Pro exekučního klienta existuje několik možností, včetně Erigon, Nethermind a Besu_. + +Aby tato dvou-klientská struktura fungovala, musí konsensuální klienti předávat balíčky transakcí exekučnímu klientovi. Exekuční klient provádí transakce lokálně, aby ověřil, že transakce neporušují žádná pravidla Etherea a že navrhovaná aktualizace stavu Etherea je správná. Když je uzel vybrán jako producent bloku, jeho instance konsensuálního klienta si vyžádá balíčky transakcí od exekučního klienta, které zahrne do nového bloku a provede je, aby aktualizoval globální stav. Konsensuální klient řídí exekučního klienta prostřednictvím místního RPC připojení pomocí [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md). + +## Co dělá exekuční klient? {#execution-client} + +Exekuční klient je zodpovědný za validaci, zpracování a šíření transakcí, spolu se správou stavu a podporou Ethereum Virtual Machine ([EVM](/developers/docs/evm/)). **Není** zodpovědný za tvorbu bloků, jejich šíření nebo za zpracování logiky konsensu. To spadá do kompetence konsensuálního klienta. + +Exekuční klient vytváří exekuční datové části – seznam transakcí, aktualizovaný stavový strom (trie) a další data související s prováděním. Konsensuální klienti zahrnují exekuční datovou část do každého bloku. Exekuční klient je také zodpovědný za opětovné provedení transakcí v nových blocích, aby se zajistila jejich platnost. Provádění transakcí probíhá na vestavěném počítači exekučního klienta, který je známý jako [Ethereum Virtual Machine (EVM)](/developers/docs/evm). + +Exekuční klient také nabízí uživatelské rozhraní k síti Ethereum prostřednictvím [metod RPC](/developers/docs/apis/json-rpc), které uživatelům umožňují dotazovat se na blockchain Etherea, odesílat transakce a nasazovat chytré kontrakty. Je běžné, že volání RPC jsou zpracovávána knihovnou jako [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/) nebo uživatelským rozhraním, jako je například peněženka v prohlížeči. + +Stručně řečeno, exekuční klient je: + +- uživatelskou bránou do Etherea +- domovem pro Ethereum Virtual Machine, stav Etherea a transakční pool. + +## Co dělá konsensuální klient? {#consensus-client} + +Konsensuální klient se zabývá veškerou logikou, která umožňuje uzlu zůstat synchronizovaný se sítí Ethereum. To zahrnuje přijímání bloků od ostatních uzlů a spouštění algoritmu pro výběr větve, který zajišťuje, že uzel vždy sleduje řetězec s největším počtem atestací (vážených efektivními zůstatky validátorů). Podobně jako exekuční klienti, i konsensuální klienti mají vlastní P2P síť, prostřednictvím které sdílejí bloky a atestace. + +Konsensuální klient se nepodílí na atestování nebo navrhování bloků – to dělá validátor, volitelný doplněk konsensuálního klienta. Konsensuální klient bez validátoru pouze sleduje vrchol řetězce, což umožňuje uzlu zůstat synchronizovaný. To umožňuje uživateli provádět transakce v síti Ethereum pomocí svého exekučního klienta s jistotou, že je na správném řetězci. + +## Validátoři {#validators} + +Staking a spuštění softwaru validátoru činí uzel způsobilým k výběru pro navržení nového bloku. Provozovatelé uzlů mohou přidat validátor ke svým konsensuálním klientům vložením 32 ETH do depozitního kontraktu. Klient validátoru je dodáván v balíku s konsensuálním klientem a může být kdykoli přidán k uzlu. Validátor se stará o atestace a návrhy bloků. Umožňuje také uzlu získávat odměny nebo ztrácet ETH prostřednictvím pokut nebo „slashingu“. + +[Více o stakingu](/staking/). + +## Porovnání komponent uzlu {#node-comparison} + +| Exekuční klient | Konsensuální klient | Validátor | +| -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------- | +| Šíří transakce přes svou P2P síť | Šíří bloky a atestace přes svou P2P síť | Navrhuje bloky | +| Provádí/znovu provádí transakce | Spouští algoritmus pro výběr větve | Získává odměny / postihy | +| Ověřuje příchozí změny stavu | Sleduje vrchol řetězce | Vytváří atestace | +| Spravuje stavové stromy (trie) a stromy (trie) účtenek | Spravuje stav Beacon Chainu (obsahuje informace o konsensu a provádění) | Vyžaduje vsadit 32 ETH. | +| Vytváří exekuční datovou část | Sleduje nahromaděnou náhodnost v RANDAO (algoritmus, který poskytuje ověřitelnou náhodnost pro výběr validátorů a další operace konsensu) | Může být podroben „slashingu“ | +| Zpřístupňuje JSON-RPC API pro interakci s Ethereem | Sleduje justifikaci a finalizaci | | + +## Další čtení {#further-reading} + +- [Důkaz podílem](/developers/docs/consensus-mechanisms/pos) +- [Návrh bloku](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [Odměny a postihy pro validátory](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/nodes-as-a-service/index.md new file mode 100644 index 00000000000..423a9bbe6a4 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -0,0 +1,418 @@ +--- +title: "Uzly jako služba" +description: "Úvodní přehled služeb uzlů, jejich výhody a nevýhody a oblíbení poskytovatelé." +lang: cs +sidebarDepth: 2 +--- + +## Úvod {#Introduction} + +Provozování vlastního [uzlu sítě Ethereum](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) může být náročné, zejména na začátku nebo při rychlém škálování. Existuje [řada služeb](#popular-node-services), které za vás provozují optimalizované infrastruktury uzlů, takže se místo toho můžete soustředit na vývoj své aplikace nebo produktu. Vysvětlíme si, jak fungují služby uzlů, jaké jsou výhody a nevýhody jejich používání, a uvedeme poskytovatele pro případ, že byste chtěli začít. + +## Předpoklady {#prerequisites} + +Pokud ještě nechápete, co jsou uzly a klienti, podívejte se na článek [Uzly a klienti](/developers/docs/nodes-and-clients/). + +## Stakeři {#stakoooooooooooooors} + +Samostatní stakeři musí provozovat vlastní infrastrukturu, místo aby se spoléhali na poskytovatele třetích stran. To znamená provozovat exekučního klienta spojeného s konsensuálním klientem. Před [Sloučením](/roadmap/merge) bylo možné provozovat pouze konsensuálního klienta a pro exekuční data využívat centralizovaného poskytovatele; to už nyní není možné – samostatný staker musí provozovat oba klienty. Existují však služby, které tento proces usnadňují. + +[Přečtěte si více o provozování uzlu](/developers/docs/nodes-and-clients/run-a-node/). + +Služby popsané na této stránce jsou pro nestakující uzly. + +## Jak fungují služby uzlů? {#how-do-node-services-work} + +Poskytovatelé služeb uzlů za vás na pozadí provozují distribuované klienty uzlů, takže vy nemusíte. + +Tyto služby obvykle poskytují klíč API, který můžete použít k zápisu a čtení z blockchainu. Často zahrnují přístup k [testovacím sítím Etherea](/developers/docs/networks/#ethereum-testnets) kromě hlavní sítě (Mainnetu). + +Některé služby vám nabízejí vlastní dedikovaný uzel, který pro vás spravují, zatímco jiné používají nástroje pro vyrovnávání zátěže (load balancery) k rozdělení aktivity mezi uzly. + +Integrace téměř všech služeb uzlů je velmi snadná a spočívá ve změně jednoho řádku kódu, kterým nahradíte svůj vlastní hostovaný uzel, nebo dokonce přepnete mezi jednotlivými službami. + +Služby uzlů často provozují různé [klienty uzlů](/developers/docs/nodes-and-clients/#execution-clients) a [typy uzlů](/developers/docs/nodes-and-clients/#node-types), což vám v jednom rozhraní API umožňuje přístup k plným a archivním uzlům a také k metodám specifickým pro klienta. + +Je důležité si uvědomit, že služby uzlů neukládají a neměly by ukládat vaše soukromé klíče ani informace. + +## Jaké jsou výhody používání služby uzlů? {#benefits-of-using-a-node-service} + +Hlavní výhodou používání služby uzlů je, že nemusíte trávit čas technickou prací s údržbou a správou vlastních uzlů. Díky tomu se můžete soustředit na tvorbu svého produktu, místo abyste se museli starat o údržbu infrastruktury. + +Provoz vlastních uzlů může být velmi nákladný, a to jak z hlediska úložiště a šířky pásma, tak i cenného času vývojářů. Činnosti jako spouštění dalších uzlů při škálování, aktualizace uzlů na nejnovější verze a zajišťování konzistence stavu mohou odvádět vaši pozornost od budování a vynakládání zdrojů na vámi požadovaný produkt web3. + +## Jaké jsou nevýhody používání služby uzlů? {#cons-of-using-a-node-service} + +Používáním služby uzlů centralizujete infrastrukturní aspekt svého produktu. Z tohoto důvodu mohou projekty, pro které je decentralizace nanejvýš důležitá, upřednostňovat vlastní hostování uzlů před outsourcingem třetí straně. + +Přečtěte si více o [výhodách provozování vlastního uzlu](/developers/docs/nodes-and-clients/#benefits-to-you). + +## Oblíbené služby uzlů {#popular-node-services} + +Zde je seznam některých nejoblíbenějších poskytovatelů uzlů sítě Ethereum. Neváhejte přidat ty, které v seznamu chybí! Každá služba uzlů nabízí kromě bezplatných nebo placených úrovní i různé výhody a funkce. Před rozhodnutím byste si měli zjistit, která z nich nejlépe vyhovuje vašim potřebám. + +- [**Alchemy**](https://alchemy.com/) + - [Dokumentace](https://www.alchemy.com/docs/) + - Funkce + - Největší bezplatná úroveň s 300 miliony výpočetních jednotek za měsíc (~30 milionů požadavků getLatestBlock) + - Podpora více řetězců pro Polygon, Starknet, Optimism, Arbitrum + - Zajišťuje provoz přibližně 70 % největších ethereových dapps a objem transakcí DeFi + - Upozornění webhooků v reálném čase prostřednictvím Alchemy Notify + - Špičková podpora a spolehlivost/stabilita + - NFT API od Alchemy + - Řídicí panel s nástroji Request Explorer, Mempool Watcher a Composer + - Integrovaný přístup k faucetu testnetu + - Aktivní komunita tvůrců na Discordu s 18 tisíci uživateli + +- [**Allnodes**](https://www.allnodes.com/) + - [Dokumentace](https://docs.allnodes.com/) + - Funkce + - Žádné limity rychlosti s tokenem PublicNode vytvořeným na stránce portfolia Allnodes. + - Bezplatné koncové body rpc zaměřené na soukromí (100+ blockchainů) na [PublicNode](https://www.publicnode.com) + - Dedikované uzly bez omezení rychlosti pro více než 90 blockchainů + - Dedikované archivní uzly pro více než 30 blockchainů + - Dostupné ve 3 regionech (USA, EU, Asie) + - Snímky pro více než 100 blockchainů na [PublicNode](https://www.publicnode.com/snapshots) + - Technická podpora 24/7 s SLA dostupností 99,90–99,98 % (v závislosti na plánu). + - Hodinová sazba + - Plaťte kreditní kartou, přes PayPal nebo v kryptoměnách + +- [**All That Node**](https://allthatnode.com/) + - [Dokumentace](https://docs.allthatnode.com/) + - Funkce + - 50 000 požadavků denně v rámci bezplatné úrovně + - Podpora pro více než 40 protokolů + - Podporovaná rozhraní JSON-RPC (EVM, Tendermint), REST a Websocket API + - Neomezený přístup k archivním datům + - Technická podpora 24/7 a více než 99,9% dostupnost + - Faucet dostupný na více řetězcích + - Neomezený přístup ke koncovým bodům s neomezeným počtem klíčů API + - Podpora Trace/Debug API + - Automatické aktualizace + +- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) + - [Dokumentace](https://aws.amazon.com/managed-blockchain/resources/) + - Funkce + - Plně spravované uzly Etherea + - Dostupné v šesti regionech + - JSON-RPC přes HTTP a zabezpečené WebSockety + - Podporuje 3 řetězce + - SLA, podpora AWS 24/7 + - Go-ethereum a Lighthouse + +- [**Ankr**](https://www.ankr.com/) + - [Dokumentace](https://docs.ankr.com/) + - Funkce + - Ankr Protocol – otevřený přístup k veřejným koncovým bodům RPC API pro více než 8 řetězců + - Vyrovnávání zátěže a sledování stavu uzlů pro rychlou a spolehlivou bránu k nejbližšímu dostupnému uzlu + - Prémiová úroveň umožňující koncový bod WSS a neomezený limit rychlosti + - Nasazení plného uzlu a uzlu validátoru na jedno kliknutí pro více než 40 řetězců + - Škálování podle potřeby + - Analytické nástroje + - Řídicí panel + - Koncové body RPC, HTTPS a WSS + - Přímá podpora + +- [**Blast**](https://blastapi.io/) + - [Dokumentace](https://docs.blastapi.io/) + - Funkce + - Podpora RPC a WSS + - Hostování uzlů ve více regionech + - Decentralizovaná infrastruktura + - Veřejné API + - Dedikovaný bezplatný plán + - Podpora více řetězců (více než 17 blockchainů) + - Archivní uzly + - Podpora 24/7 na Discordu + - Monitorování a upozornění 24/7 + - Celková SLA 99,9 % + - Platba v kryptoměnách + +- [**BlockDaemon**](https://blockdaemon.com/) + - [Dokumentace](https://ubiquity.docs.blockdaemon.com/) + - Výhody + - Řídicí panel + - Na bázi jednotlivých uzlů + - Analytika + +- [**BlockPI**](https://blockpi.io/) + - [Dokumentace](https://docs.blockpi.io/) + - Funkce + - Robustní a distribuovaná struktura uzlů + - Až 40 koncových bodů HTTPS a WSS + - Bezplatný registrační balíček a měsíční balíček + - Metoda sledování + podpora archivních dat + - Balíčky s platností až 90 dní + - Vlastní plán a průběžné platby + - Platba v kryptoměnách + - Přímá podpora a technická podpora + +- [**Chainbase**](https://www.chainbase.com/) + - [Dokumentace](https://docs.chainbase.com) + - Funkce + - Vysoce dostupná, rychlá a škálovatelná služba RPC + - Podpora více řetězců + - Bezplatné tarify + - Uživatelsky přívětivý řídicí panel + - Poskytuje služby blockchainových dat nad rámec RPC + +- [**Chainstack**](https://chainstack.com/) + - [Dokumentace](https://docs.chainstack.com/) + - Funkce + - Bezplatné sdílené uzly + - Sdílené archivní uzly + - Podpora GraphQL + - Koncové body RPC a WSS + - Dedikované plné a archivní uzly + - Rychlá synchronizace pro dedikovaná nasazení + - Použití vlastního cloudu + - Hodinová sazba + - Přímá podpora 24/7 + +- [**dRPC**](https://drpc.org/) + - [Dokumentace](https://drpc.org/docs) + - NodeCloud: Plug-n-play RPC infrastruktura od 10 USD – plná rychlost, bez omezení + - Funkce NodeCloud: + - Podpora API pro 185 sítí + - Distribuovaný pool více než 40 poskytovatelů + - Globální pokrytí s devíti (9) geografickými clustery + - Systém vyrovnávání zátěže s umělou inteligencí + - Paušální průběžné platby – žádné zdražování, žádné vypršení platnosti, žádné závazky + - Neomezené klíče, granulární úpravy klíčů, týmové role, front-endová ochrana + - Paušální sazba 20 výpočetních jednotek (CU) za metodu + - [Seznam veřejných koncových bodů](https://drpc.org/chainlist) + - [Kalkulačka cen](https://drpc.org/pricing#calculator) + - NodeCore: open-source stack pro organizace, které chtějí plnou kontrolu + +- [**GetBlock**](https://getblock.io/) + - [Dokumentace](https://getblock.io/docs/get-started/authentication-with-api-key/) + - Funkce + - Přístup k více než 40 blockchainovým uzlům + - 40 tisíc bezplatných požadavků denně + - Neomezený počet klíčů API + - Vysoká rychlost připojení 1 GB/s + - Sledování+archivace + - Pokročilá analytika + - Automatické aktualizace + - Technická podpora + +- [**InfStones**](https://infstones.com/) + - Funkce + - Možnost bezplatné úrovně + - Škálování podle potřeby + - Analytika + - Řídicí panel + - Unikátní koncové body API + - Dedikované plné uzly + - Rychlá synchronizace pro dedikovaná nasazení + - Přímá podpora 24/7 + - Přístup k více než 50 blockchainovým uzlům + +- [**Infura**](https://infura.io/) + - [Dokumentace](https://infura.io/docs) + - Funkce + - Možnost bezplatné úrovně + - Škálování podle potřeby + - Placená archivní data + - Přímá podpora + - Řídicí panel + +- [**Kaleido**](https://kaleido.io/) + - [Dokumentace](https://docs.kaleido.io/) + - Funkce + - Bezplatná úroveň pro začátečníky + - Nasazení uzlu Etherea na jedno kliknutí + - Přizpůsobitelní klienti a algoritmy (Geth, Quorum a Besu || PoA, IBFT a Raft) + - Více než 500 administrativních a servisních API + - RESTful rozhraní pro odesílání transakcí Etherea (zajištěno Apache Kafka) + - Odchozí streamy pro doručování událostí (zajištěno Apache Kafka) + - Rozsáhlá sbírka „offchainových“ a doplňkových služeb (např. bilaterální přenos šifrovaných zpráv) + - Jednoduché zprovoznění sítě se správou a řízením přístupu na základě rolí + - Sofistikovaná správa uživatelů pro administrátory i koncové uživatele + - Vysoce škálovatelná, odolná infrastruktura podnikové úrovně + - Správa soukromých klíčů pomocí cloudového HSM + - Propojení s hlavní sítí Etherea (tethering) + - Certifikace ISO 27k a SOC 2, typ 2 + - Dynamická konfigurace za běhu (např. přidávání cloudových integrací, změna vstupních bodů uzlů atd.) + - Podpora pro multi-cloudové, multi-regionální a hybridní orchestrace nasazení + - Jednoduchá hodinová sazba na bázi SaaS + - SLA a podpora 24/7 + +- [**Lava Network**](https://www.lavanet.xyz/) + - [Dokumentace](https://docs.lavanet.xyz/) + - Funkce + - Bezplatné použití testnetu + - Decentralizovaná redundance pro vysokou dostupnost + - Open-source + - Plně decentralizované SDK + - Integrace s Ethers.js + - Intuitivní rozhraní pro správu projektů + - Integrita dat založená na konsensu + - Podpora více řetězců + +- [**Moralis**](https://moralis.io/) + - [Dokumentace](https://docs.moralis.io/) + - Funkce + - Bezplatné sdílené uzly + - Bezplatné sdílené archivní uzly + - Zaměřeno na soukromí (zásada neukládání záznamů) + - Podpora více řetězců + - Škálování podle potřeby + - Řídicí panel + - Unikátní SDK pro Ethereum + - Unikátní koncové body API + - Přímá technická podpora + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [Dokumentace](https://docs.nodereal.io/docs/introduction) + - Funkce + - Spolehlivé, rychlé a škálovatelné služby RPC API + - Vylepšené API pro vývojáře web3 + - Podpora více řetězců + - Začněte zdarma + +- [**NOWNodes**](https://nownodes.io/) + - [Dokumentace](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - Funkce + - Přístup k více než 50 blockchainovým uzlům + - Bezplatný klíč API + - Prohlížeče bloků + - Doba odezvy API ⩽ 1 s + - Tým podpory 24/7 + - Osobní správce účtu + - Sdílené, archivní, záložní a dedikované uzly + +- [**Pocket Network**](https://www.pokt.network/) + - [Dokumentace](https://docs.pokt.network/home/) + - Funkce + - Decentralizovaný RPC protokol a tržiště + - 1 milion požadavků denně v rámci bezplatné úrovně (na koncový bod, max. 2) + - [Veřejné koncové body](https://docs.pokt.network/developers/public-endpoints) + - Program Pre-Stake+ (pokud potřebujete více než 1 milion požadavků denně) + - Podpora více než 15 blockchainů + - Více než 6400 uzlů vydělávajících POKT za obsluhu aplikací + - Podpora archivních uzlů, archivních uzlů se sledováním a uzlů testnetu + - Diverzita klientů uzlů hlavní sítě Etherea + - Žádný jediný bod selhání + - Nulové prostoje + - Cenově efektivní tokenomika s téměř nulovými náklady (jednou stakujte POKT za šířku pásma sítě) + - Žádné měsíční utopené náklady, přeměňte svou infrastrukturu na aktivum + - Vyrovnávání zátěže zabudované v protokolu + - Nekonečné škálování počtu požadavků za den a uzlů za hodinu podle potřeby + - Nejsoukromější a nejodolnější možnost proti cenzuře + - Praktická podpora pro vývojáře + - Řídicí panel a analytika [Pocket Portal](https://bit.ly/ETHorg_POKTportal) + +- [**QuickNode**](https://www.quicknode.com) + - [Dokumentace](https://www.quicknode.com/docs/) + - Funkce + - Technická podpora 24/7 a vývojářská komunita na Discordu + - Geograficky vyvážená síť s nízkou latencí, multi-cloud/metal + - Podpora více řetězců (Optimism, Arbitrum, Polygon + 11 dalších) + - Střední vrstvy pro rychlost a stabilitu (směrování volání, cache, indexování) + - Monitorování chytrých kontraktů přes Webhooky + - Intuitivní řídicí panel, sada analytických nástrojů, skladatel RPC + - Pokročilé bezpečnostní funkce (JWT, maskování, whitelisting) + - API pro NFT data a analytiku + - [Certifikováno SOC2](https://www.quicknode.com/security) + - Vhodné pro vývojáře i podniky + +- [**Rivet**](https://rivet.cloud/) + - [Dokumentace](https://rivet.readthedocs.io/en/latest/) + - Funkce + - Možnost bezplatné úrovně + - Škálování podle potřeby + +- [**SenseiNode**](https://senseinode.com) + - [Dokumentace](https://docs.senseinode.com/) + - Funkce + - Dedikované a sdílené uzly + - Řídicí panel + - Hostování mimo AWS u více poskytovatelů hostingu v různých lokalitách v Latinské Americe + - Klienti Prysm a Lighthouse + +- [**SettleMint**](https://console.settlemint.com/) + - [Dokumentace](https://docs.settlemint.com/) + - Funkce + - Zkušební verze zdarma + - Škálování podle potřeby + - Podpora GraphQL + - Koncové body RPC a WSS + - Dedikované plné uzly + - Použití vlastního cloudu + - Analytické nástroje + - Řídicí panel + - Hodinová sazba + - Přímá podpora + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [Dokumentace](https://docs.tenderly.co/web3-gateway/web3-gateway) + - Funkce + - Bezplatná úroveň zahrnující 25 milionů jednotek Tenderly měsíčně + - Bezplatný přístup k historickým datům + - Až 8x rychlejší pracovní zátěž s velkým objemem čtení + - 100% konzistentní přístup ke čtení + - Koncové body JSON-RPC + - Tvůrce požadavků RPC založený na uživatelském rozhraní a náhled požadavků + - Úzce integrováno s vývojovými, ladicími a testovacími nástroji Tenderly + - Simulace transakcí + - Analytika použití a filtrování + - Snadná správa přístupových klíčů + - Dedikovaná technická podpora přes chat, e-mail a Discord + +- [**Tokenview**](https://services.tokenview.io/) + - [Dokumentace](https://services.tokenview.io/docs?type=nodeService) + - Funkce + - Technická podpora 24/7 a vývojářská komunita na Telegramu + - Podpora více řetězců (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic) + - K dispozici jsou koncové body RPC i WSS + - Neomezený přístup k API pro archivní data + - Řídicí panel s nástroji Request Explorer a Mempool Watcher + - API pro NFT data a upozornění přes Webhook + - Platba v kryptoměnách + - Externí podpora pro další požadavky na chování + +- [**Watchdata**](https://watchdata.io/) + - [Dokumentace](https://docs.watchdata.io/) + - Funkce + - Spolehlivost dat + - Nepřetržité připojení bez prostojů + - Automatizace procesů + - Bezplatné tarify + - Vysoké limity, které vyhovují každému uživateli + - Podpora různých uzlů + - Škálování zdrojů + - Vysoké rychlosti zpracování + +- [**ZMOK**](https://zmok.io/) + - [Dokumentace](https://docs.zmok.io/) + - Funkce + - Front-running jako služba + - Globální mempool transakcí s metodami vyhledávání/filtrování + - Neomezený poplatek za transakci a nekonečný gas pro odesílání transakcí + - Nejrychlejší získání nového bloku a čtení z blockchainu + - Záruka nejlepší ceny za volání API + +- [**Zeeve**](https://www.zeeve.io/) + - [Dokumentace](https://www.zeeve.io/docs/) + - Funkce + - Automatizační platforma podnikové třídy bez nutnosti kódování, která poskytuje nasazení, monitorování a správu blockchainových uzlů a sítí + - Více než 30 podporovaných protokolů a integrací a další přibývají + - Služby infrastruktury web3 s přidanou hodnotou, jako je decentralizované úložiště, decentralizovaná identita a API pro data z blockchainové účetní knihy pro reálné případy použití + - Podpora 24/7 a proaktivní monitorování zajišťují neustálý bezproblémový stav uzlů. + - Koncové body RPC nabízejí ověřený přístup k API, bezproblémovou správu s intuitivním řídicím panelem a analytikou. + - Poskytuje možnost volby mezi spravovaným cloudem a vlastním cloudem a podporuje všechny hlavní poskytovatele cloudu, jako jsou AWS, Azure, Google Cloud, Digital Ocean a on-premise. + - Používáme inteligentní směrování, abychom pokaždé zasáhli uzel nejblíže vašemu uživateli + +## Další čtení {#further-reading} + +- [Seznam služeb uzlů Etherea](https://ethereumnodes.com/) + +## Související témata {#related-topics} + +- [Uzly a klienti](/developers/docs/nodes-and-clients/) + +## Související návody {#related-tutorials} + +- [Začínáme s vývojem na Ethereu pomocí Alchemy](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [Průvodce odesíláním transakcí pomocí web3 a Alchemy](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/run-a-node/index.md new file mode 100644 index 00000000000..89ec933a3db --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/run-a-node/index.md @@ -0,0 +1,484 @@ +--- +title: "Spusťte si vlastní uzel Etherea" +description: "Obecný úvod do spouštění vlastní instance klienta Etherea." +lang: cs +sidebarDepth: 2 +--- + +Provozování vlastního uzlu vám přináší různé výhody, otevírá nové možnosti a pomáhá podporovat ekosystém. Tato stránka vás provede spuštěním vlastního uzlu a účastí na validaci ethereových transakcí. + +Všimněte si, že po [Sloučení](/roadmap/merge) jsou k provozu uzlu Etherea zapotřebí dva klienti: klient **exekuční vrstvy (EL)** a klient **konsensuální vrstvy (CL)**. Tato stránka vám ukáže, jak nainstalovat, nakonfigurovat a připojit tyto dva klienty k provozu uzlu Etherea. + +## Předpoklady {#prerequisites} + +Měli byste rozumět tomu, co je uzel Etherea a proč byste mohli chtít provozovat klienta. Toto je popsáno v části [Uzly a klienti](/developers/docs/nodes-and-clients/). + +Pokud jste v tématu provozování uzlu nováčkem nebo hledáte méně technickou cestu, doporučujeme nejprve se podívat na náš uživatelsky přívětivý úvod do [provozování uzlu Etherea](/run-a-node). + +## Výběr přístupu {#choosing-approach} + +Prvním krokem při spouštění uzlu je výběr přístupu. Na základě požadavků a různých možností si musíte vybrat implementaci klienta (exekučního i konsensuálního klienta), prostředí (hardware, systém) a parametry pro nastavení klienta. + +Tato stránka vás provede těmito rozhodnutími a pomůže vám najít nejvhodnější způsob, jak provozovat vaši instanci Etherea. + +Chcete-li si vybrat z implementací klientů, podívejte se na všechny dostupné [exekuční klienty](/developers/docs/nodes-and-clients/#execution-clients) a [konsensuální klienty](/developers/docs/nodes-and-clients/#consensus-clients) připravené pro Mainnet a přečtěte si o [diverzitě klientů](/developers/docs/nodes-and-clients/client-diversity). + +Rozhodněte se, zda chcete software provozovat na vlastním [hardwaru nebo v cloudu](#local-vs-cloud), a zvažte [požadavky](#requirements) klientů. + +Po přípravě prostředí nainstalujte vybrané klienty buď pomocí [rozhraní pro začátečníky](#automatized-setup), nebo [ručně](#manual-setup) pomocí terminálu s pokročilými možnostmi. + +Když je uzel spuštěn a synchronizuje se, jste připraveni [jej používat](#using-the-node), ale nezapomeňte dohlížet na jeho [údržbu](#operating-the-node). + +![Nastavení klienta](./diagram.png) + +### Prostředí a hardware {#environment-and-hardware} + +#### Lokálně nebo v cloudu {#local-vs-cloud} + +Klienti Etherea mohou běžet na běžných počítačích a nevyžadují žádný speciální hardware, jako například těžařské stroje. Proto máte na základě svých potřeb různé možnosti nasazení uzlu. +Pro zjednodušení si představme provoz uzlu na lokálním fyzickém stroji i na cloudovém serveru: + +- Cloud + - Poskytovatelé nabízejí vysokou dostupnost serverů a statické veřejné IP adresy + - Pořízení dedikovaného nebo virtuálního serveru může být pohodlnější než stavba vlastního + - Kompromisem je důvěra třetí straně – poskytovateli serveru + - Vzhledem k požadované velikosti úložiště pro plný uzel může být cena pronajatého serveru vysoká +- Vlastní hardware + - Více suverénní přístup, který nevyžaduje důvěru. + - Jednorázová investice + - Možnost zakoupení předkonfigurovaných strojů + - Musíte fyzicky připravit, udržovat a případně řešit problémy se strojem a sítí + +Obě možnosti mají různé výhody, které jsou shrnuty výše. Pokud hledáte cloudové řešení, kromě mnoha tradičních poskytovatelů cloudových služeb existují také služby zaměřené na nasazování uzlů. Podívejte se na [uzly jako službu](/developers/docs/nodes-and-clients/nodes-as-a-service/), kde naleznete více možností pro hostované uzly. + +#### Hardware {#hardware} + +Decentralizovaná síť odolná vůči cenzuře by se však neměla spoléhat na poskytovatele cloudových služeb. Místo toho je pro ekosystém zdravější provozovat uzel na vlastním lokálním hardwaru. [Odhady](https://www.ethernodes.org/networkType/cl/Hosting) ukazují, že velká část uzlů běží v cloudu, což by se mohlo stát jediným bodem selhání. + +Klienti Etherea mohou běžet na vašem počítači, notebooku, serveru nebo dokonce na jednodeskovém počítači. I když je možné provozovat klienty na osobním počítači, mít vyhrazený stroj pouze pro váš uzel může výrazně zvýšit jeho výkon a bezpečnost a zároveň minimalizovat dopad na váš primární počítač. + +Používání vlastního hardwaru může být velmi snadné. Existuje mnoho jednoduchých možností i pokročilých nastavení pro technicky zdatnější lidi. Pojďme se tedy podívat na požadavky a prostředky pro provozování klientů Etherea na vašem stroji. + +#### Požadavky {#requirements} + +Hardwarové požadavky se liší podle klienta, ale obecně nejsou tak vysoké, protože uzel musí pouze zůstat synchronizovaný. Nezaměňujte to s těžbou, která vyžaduje mnohem větší výpočetní výkon. Doba synchronizace a výkon se však s výkonnějším hardwarem zlepšují. + +Před instalací jakéhokoli klienta se prosím ujistěte, že váš počítač má dostatek zdrojů pro jeho provoz. Minimální a doporučené požadavky naleznete níže. + +Úzkým hrdlem pro váš hardware je většinou místo na disku. Synchronizace blockchainu Etherea je velmi náročná na vstup/výstup a vyžaduje hodně místa. Nejlepší je mít **disk SSD (solid-state drive)** se stovkami GB volného místa i po synchronizaci. + +Velikost databáze a rychlost počáteční synchronizace závisí na zvoleném klientovi, jeho konfiguraci a [strategii synchronizace](/developers/docs/nodes-and-clients/#sync-modes). + +Také se ujistěte, že vaše internetové připojení není omezeno [datovým limitem](https://wikipedia.org/wiki/Data_cap). Doporučuje se používat připojení bez měření, protože počáteční synchronizace a data vysílaná do sítě by mohla překročit váš limit. + +##### Operační systém + +Všichni klienti podporují hlavní operační systémy – Linux, MacOS, Windows. To znamená, že uzly můžete provozovat na běžných stolních počítačích nebo serverech s operačním systémem (OS), který vám nejvíce vyhovuje. Ujistěte se, že je váš operační systém aktuální, abyste se vyhnuli potenciálním problémům a bezpečnostním zranitelnostem. + +##### Minimální požadavky + +- CPU s 2 a více jádry +- 8 GB RAM +- 2TB SSD +- Šířka pásma 10+ MBit/s + +##### Doporučené specifikace + +- Rychlý CPU se 4 a více jádry +- 16 GB+ RAM +- Rychlý SSD s 2+ TB +- Šířka pásma 25+ MBit/s + +Režim synchronizace a klient, kterého si vyberete, ovlivní požadavky na prostor, ale níže jsme odhadli místo na disku, které budete pro každého klienta potřebovat. + +| Klient | Velikost disku (snap sync) | Velikost disku (plný archiv) | +| ---------- | --------------------------------------------- | ----------------------------------------------- | +| Besu | 800 GB+ | 12 TB+ | +| Erigon | Není k dispozici | 2,5 TB+ | +| Geth | 500 GB+ | 12 TB+ | +| Nethermind | 500 GB+ | 12 TB+ | +| Reth | Není k dispozici | 2,2 TB+ | + +- Poznámka: Erigon a Reth nenabízejí snap sync, ale je možné úplné prořezávání (Full Pruning) (~2 TB pro Erigon, ~1,2 TB pro Reth) + +U konsensuálních klientů závisí požadavek na prostor také na implementaci klienta a povolených funkcích (např. validator slasher), ale obecně počítejte s dalšími 200 GB potřebnými pro data beaconu. S velkým počtem validátorů roste i zatížení šířky pásma. [Podrobnosti o požadavcích na konsensuální klienty naleznete v této analýze](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). + +#### Plug-and-play řešení {#plug-and-play} + +Nejjednodušší možností pro provozování uzlu na vlastním hardwaru je použití plug-and-play boxů. Předkonfigurované stroje od prodejců nabízejí nejpřímočařejší zážitek: objednat, připojit, spustit. Vše je předkonfigurováno a běží automaticky s intuitivním průvodcem a řídicím panelem pro monitorování a ovládání softwaru. + +- [DappNode](https://dappnode.io/) +- [Avado](https://ava.do/) + +#### Ethereum na jednodeskovém počítači {#ethereum-on-a-single-board-computer} + +Snadný a levný způsob, jak provozovat uzel Etherea, je použít jednodeskový počítač, a to i s architekturou ARM, jako je Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) poskytuje snadno spustitelné obrazy několika exekučních a konsensuálních klientů pro Raspberry Pi a další desky ARM. + +Malá, cenově dostupná a efektivní zařízení, jako jsou tato, jsou ideální pro provoz uzlu doma, ale mějte na paměti jejich omezený výkon. + +## Spuštění uzlu {#spinning-up-node} + +Vlastní nastavení klienta lze provést buď pomocí automatizovaných spouštěčů, nebo ručně, přímým nastavením softwaru klienta. + +Pro méně pokročilé uživatele je doporučeným přístupem použití spouštěče, softwaru, který vás provede instalací a automatizuje proces nastavení klienta. Pokud však máte nějaké zkušenosti s používáním terminálu, kroky pro ruční nastavení by měly být snadno proveditelné. + +### Nastavení s průvodcem {#automatized-setup} + +Několik uživatelsky přívětivých projektů si klade za cíl zlepšit zážitek z nastavování klienta. Tyto spouštěče poskytují automatickou instalaci a konfiguraci klienta, přičemž některé dokonce nabízejí grafické rozhraní pro nastavení s průvodcem a monitorování klientů. + +Níže je uvedeno několik projektů, které vám mohou pomoci nainstalovat a ovládat klienty na pár kliknutí: + +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) – DappNode není dodáván pouze se strojem od prodejce. Software, samotný spouštěč uzlu a řídicí centrum s mnoha funkcemi lze použít na libovolném hardwaru. +- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) – Nejrychlejší a nejjednodušší způsob nastavení plného uzlu. Jednořádkový instalační nástroj a TUI pro správu uzlů. Zdarma. Open source. Veřejné statky pro Ethereum od sólo stakerů. Podpora ARM64 a AMD64. +- [eth-docker](https://eth-docker.net/) – Automatizované nastavení pomocí Dockeru zaměřené na snadný a bezpečný staking, vyžaduje základní znalosti terminálu a Dockeru, doporučeno pro mírně pokročilejší uživatele. +- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) – Spouštěč pro instalaci klientů na vzdálený server přes SSH připojení s průvodcem nastavení v GUI, řídicím centrem a mnoha dalšími funkcemi. +- [NiceNode](https://www.nicenode.xyz/) – Spouštěč s přímočarým uživatelským zážitkem pro spuštění uzlu na vašem počítači. Stačí si vybrat klienty a spustit je na pár kliknutí. Stále ve vývoji. +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) – Nástroj pro nastavení uzlu, který automaticky generuje konfiguraci Dockeru pomocí průvodce CLI. Napsáno v Go od Nethermind. + +### Ruční nastavení klientů {#manual-setup} + +Druhou možností je ruční stažení, ověření a konfigurace softwaru klienta. I když někteří klienti nabízejí grafické rozhraní, ruční nastavení stále vyžaduje základní dovednosti s terminálem, ale nabízí mnohem větší všestrannost. + +Jak bylo vysvětleno dříve, nastavení vlastního uzlu Etherea bude vyžadovat spuštění páru konsensuálního a exekučního klienta. Někteří klienti mohou obsahovat odlehčeného klienta (light client) druhého typu a synchronizovat se bez potřeby dalšího softwaru. Úplné ověření nevyžadující důvěru však vyžaduje obě implementace. + +#### Získání softwaru klienta {#getting-the-client} + +Nejprve musíte získat software preferovaného [exekučního klienta](/developers/docs/nodes-and-clients/#execution-clients) a [konsensuálního klienta](/developers/docs/nodes-and-clients/#consensus-clients). + +Můžete si jednoduše stáhnout spustitelnou aplikaci nebo instalační balíček, který vyhovuje vašemu operačnímu systému a architektuře. Vždy ověřujte podpisy a kontrolní součty stažených balíčků. Někteří klienti také nabízejí repozitáře nebo obrazy Docker pro snadnější instalaci a aktualizace. Všichni klienti jsou open source, takže si je můžete také sestavit ze zdrojového kódu. Toto je pokročilejší metoda, ale v některých případech může být vyžadována. + +Pokyny k instalaci každého klienta jsou uvedeny v dokumentaci, na kterou odkazují seznamy klientů výše. + +Zde jsou stránky s vydáními klientů, kde naleznete jejich předpřipravené binární soubory nebo pokyny k instalaci: + +##### Exekuční klienti + +- [Besu](https://github.com/hyperledger/besu/releases) +- [Erigon](https://github.com/ledgerwatch/erigon/releases) +- [Geth](https://geth.ethereum.org/downloads/) +- [Nethermind](https://downloads.nethermind.io/) +- [Reth](https://reth.rs/installation/installation.html) + +Je také třeba poznamenat, že diverzita klientů je [problémem na exekuční vrstvě](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Doporučuje se, aby čtenáři zvážili provozování menšinového exekučního klienta. + +##### Konsenzuální klienti + +- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source) (Neposkytuje předpřipravený binární soubor, pouze obraz Dockeru nebo je nutné jej sestavit ze zdrojového kódu) +- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) +- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) +- [Teku](https://github.com/ConsenSys/teku/releases) + +[Diverzita klientů](/developers/docs/nodes-and-clients/client-diversity/) je klíčová pro konsensuální uzly provozující validátory. Pokud většina validátorů provozuje jedinou implementaci klienta, je ohrožena bezpečnost sítě. Proto se doporučuje zvážit výběr menšinového klienta. + +[Podívejte se na nejnovější využití síťových klientů](https://clientdiversity.org/) a zjistěte více o [diverzitě klientů](/developers/docs/nodes-and-clients/client-diversity). + +##### Ověření softwaru + +Při stahování softwaru z internetu se doporučuje ověřit jeho integritu. Tento krok je nepovinný, ale zejména u klíčové části infrastruktury, jako je klient Etherea, je důležité si uvědomit potenciální vektory útoku a vyhnout se jim. Pokud jste si stáhli předpřipravený binární soubor, musíte mu důvěřovat a riskovat, že by útočník mohl spustitelný soubor vyměnit za škodlivý. + +Vývojáři podepisují vydané binární soubory svými klíči PGP, takže si můžete kryptograficky ověřit, že spouštíte přesně ten software, který vytvořili. Stačí získat veřejné klíče používané vývojáři, které naleznete na stránkách s vydáními klientů nebo v dokumentaci. Po stažení vydání klienta a jeho podpisu je můžete snadno ověřit pomocí implementace PGP, např. [GnuPG](https://gnupg.org/download/index.html). Podívejte se na návod k ověřování open-source softwaru pomocí `gpg` na [Linuxu](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) nebo [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/). + +Další formou ověření je ujistit se, že haš, jedinečný kryptografický otisk, softwaru, který jste stáhli, se shoduje s tím, který poskytli vývojáři. To je ještě jednodušší než použití PGP a někteří klienti nabízejí pouze tuto možnost. Stačí spustit hašovací funkci na staženém softwaru a porovnat ji s tou ze stránky vydání. Například: + +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### Nastavení klienta {#client-setup} + +Po instalaci, stažení nebo zkompilování softwaru klienta jste připraveni jej spustit. To pouze znamená, že musí být spuštěn se správnou konfigurací. Klienti nabízejí bohaté možnosti konfigurace, které mohou povolit různé funkce. + +Začněme možnostmi, které mohou výrazně ovlivnit výkon klienta a využití dat. [Režimy synchronizace](/developers/docs/nodes-and-clients/#sync-modes) představují různé metody stahování a validace dat blockchainu. Před spuštěním uzlu byste se měli rozhodnout, jakou síť a režim synchronizace použít. Nejdůležitějšími věcmi, které je třeba zvážit, jsou místo na disku a doba synchronizace, kterou bude klient potřebovat. Věnujte pozornost dokumentaci klienta, abyste zjistili, který režim synchronizace je výchozí. Pokud vám to nevyhovuje, vyberte si jiný na základě úrovně zabezpečení, dostupných dat a nákladů. Kromě synchronizačního algoritmu můžete také nastavit prořezávání (pruning) různých druhů starých dat. Prořezávání (pruning) umožňuje mazat zastaralá data, tj. odstraňovat uzly stavového trie, které jsou nedosažitelné z posledních bloků. + +Další základní možnosti konfigurace jsou např. výběr sítě – Mainnet nebo testnety, povolení HTTP endpointu pro RPC nebo WebSockets atd. Všechny funkce a možnosti naleznete v dokumentaci klienta. Různé konfigurace klienta lze nastavit spuštěním klienta s odpovídajícími příznaky přímo v CLI nebo konfiguračním souboru. Každý klient je trochu jiný; podrobnosti o možnostech konfigurace naleznete vždy v jeho oficiální dokumentaci nebo na stránce nápovědy. + +Pro účely testování můžete preferovat spuštění klienta na jedné z testovacích sítí. [Podívejte se na přehled podporovaných sítí](/developers/docs/nodes-and-clients/#execution-clients). + +Příklady spuštění exekučních klientů se základní konfigurací naleznete v další části. + +#### Spuštění exekučního klienta {#starting-the-execution-client} + +Před spuštěním softwaru klienta Etherea proveďte poslední kontrolu, zda je vaše prostředí připraveno. Například se ujistěte, že: + +- Je dostatek místa na disku s ohledem na zvolenou síť a režim synchronizace. +- Paměť a CPU nejsou vytíženy jinými programy. +- Operační systém je aktualizován na nejnovější verzi. +- Systém má správný čas a datum. +- Váš router a firewall přijímají připojení na naslouchajících portech. Ve výchozím nastavení používají klienti Etherea naslouchací port (TCP) a port pro zjišťování (UDP), oba ve výchozím nastavení na 30303. + +Nejprve spusťte klienta na testnetu, abyste se ujistili, že vše funguje správně. + +Na začátku musíte deklarovat všechna nastavení klienta, která nejsou výchozí. Pro deklarování preferované konfigurace můžete použít příznaky nebo konfigurační soubor. Sada funkcí a syntaxe konfigurace se u každého klienta liší. Specifika naleznete v dokumentaci vašeho klienta. + +Exekuční a konsensuální klienti komunikují prostřednictvím ověřeného koncového bodu specifikovaného v [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). Aby se mohl exekuční klient připojit ke konsensuálnímu klientovi, musí vygenerovat [`jwtsecret`](https://jwt.io/) ve známé cestě. Z bezpečnostních a stabilizačních důvodů by klienti měli běžet na stejném stroji a oba klienti musí znát tuto cestu, protože se používá k ověření lokálního připojení RPC mezi nimi. Exekuční klient musí také definovat naslouchací port pro ověřená API. + +Tento token je generován automaticky softwarem klienta, ale v některých případech jej možná budete muset vytvořit sami. Můžete jej vygenerovat pomocí [OpenSSL](https://www.openssl.org/): + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### Spuštění exekučního klienta {#running-an-execution-client} + +Tato část vás provede spuštěním exekučních klientů. Slouží pouze jako příklad základní konfigurace, která spustí klienta s těmito nastaveními: + +- Určuje síť pro připojení, v našich příkladech Mainnet + - Pro předběžné testování vašeho nastavení si můžete místo toho vybrat [jeden z testnetů](/developers/docs/networks/) +- Definuje datový adresář, kde budou uložena všechna data včetně blockchainu + - Ujistěte se, že cestu nahradíte skutečnou, např. odkazující na váš externí disk +- Povoluje rozhraní pro komunikaci s klientem + - Včetně JSON-RPC a Engine API pro komunikaci s konsensuálním klientem +- Definuje cestu k `jwtsecret` pro ověřené API + - Ujistěte se, že příkladovou cestu nahradíte skutečnou, ke které mají klienti přístup, např. `/tmp/jwtsecret` + +Mějte na paměti, že se jedná pouze o základní příklad, všechna ostatní nastavení budou nastavena na výchozí hodnoty. Věnujte pozornost dokumentaci každého klienta, abyste se dozvěděli o výchozích hodnotách, nastaveních a funkcích. Pro více funkcí, například pro provozování validátorů, monitorování atd., se prosím obraťte na dokumentaci konkrétního klienta. + +> Všimněte si, že zpětná lomítka `` v příkladech slouží pouze pro účely formátování; konfigurační příznaky lze definovat na jednom řádku. + +##### Spuštění Besu + +Tento příklad spouští Besu na Mainnetu, ukládá data blockchainu ve výchozím formátu na `/data/ethereum`, povoluje JSON-RPC a Engine RPC pro připojení konsensuálního klienta. Engine API je ověřeno tokenem `jwtsecret` a jsou povolána pouze volání z `localhost`. + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +Besu také přichází s možností spouštěče, který položí řadu otázek a vygeneruje konfigurační soubor. Spusťte interaktivní spouštěč pomocí: + +```sh +besu --Xlauncher +``` + +[Dokumentace Besu](https://besu.hyperledger.org/public-networks/get-started/start-node/) obsahuje další možnosti a podrobnosti o konfiguraci. + +##### Spuštění Erigonu + +Tento příklad spouští Erigon na Mainnetu, ukládá data blockchainu na `/data/ethereum`, povoluje JSON-RPC, definuje, které jmenné prostory jsou povoleny, a povoluje ověřování pro připojení konsensuálního klienta, což je definováno cestou k `jwtsecret`. + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Erigon ve výchozím nastavení provádí plnou synchronizaci s 8GB HDD, což bude mít za následek více než 2 TB archivních dat. Ujistěte se, že `datadir` ukazuje na disk s dostatkem volného místa, nebo se podívejte na příznak `--prune`, který může oříznout různé druhy dat. Pro více informací se podívejte na `--help` Erigonu. + +##### Spuštění Gethu + +Tento příklad spouští Geth na Mainnetu, ukládá data blockchainu na `/data/ethereum`, povoluje JSON-RPC a definuje, které jmenné prostory jsou povoleny. Také povoluje ověřování pro připojení konsensuálního klienta, což vyžaduje cestu k `jwtsecret` a také možnost definující, která připojení jsou povolena, v našem příkladu pouze z `localhost`. + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Podívejte se na [dokumentaci pro všechny možnosti konfigurace](https://geth.ethereum.org/docs/fundamentals/command-line-options) a dozvíte se více o [provozování Gethu s konsensuálním klientem](https://geth.ethereum.org/docs/getting-started/consensus-clients). + +##### Spuštění Nethermindu + +Nethermind nabízí různé [možnosti instalace](https://docs.nethermind.io/get-started/installing-nethermind). Balíček obsahuje různé binární soubory, včetně spouštěče s průvodcem nastavení, který vám pomůže interaktivně vytvořit konfiguraci. Alternativně najdete Runner, což je samotný spustitelný soubor, a můžete jej spustit s konfiguračními příznaky. JSON-RPC je ve výchozím nastavení povoleno. + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +Dokumentace Nethermind nabízí [kompletního průvodce](https://docs.nethermind.io/get-started/running-node/) provozováním Nethermindu s konsensuálním klientem. + +Exekuční klient spustí své základní funkce, zvolené koncové body a začne hledat peery. Po úspěšném nalezení peerů klient zahájí synchronizaci. Exekuční klient bude čekat na připojení od konsensuálního klienta. Aktuální data blockchainu budou k dispozici, jakmile bude klient úspěšně synchronizován s aktuálním stavem. + +##### Spuštění Reth + +Tento příklad spouští Reth na Mainnetu s použitím výchozího umístění dat. Povoluje JSON-RPC a ověřování Engine RPC pro připojení konsensuálního klienta, což je definováno cestou k `jwtsecret`, přičemž jsou povolena pouze volání z `localhost`. + +```sh +reth node \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +Podívejte se na [Konfigurace Reth](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), abyste se dozvěděli více o výchozích datových adresářích. [Dokumentace Reth](https://reth.rs/run/mainnet.html) obsahuje další možnosti a podrobnosti o konfiguraci. + +#### Spuštění konsensuálního klienta {#starting-the-consensus-client} + +Konsensuální klient musí být spuštěn se správnou konfigurací portu, aby se navázalo lokální připojení RPC k exekučnímu klientovi. Konsensuální klienti musí být spuštěni s portem vystaveným exekučním klientem jako konfiguračním argumentem. + +Konsensuální klient také potřebuje cestu k souboru `jwt-secret` exekučního klienta, aby mohl ověřit připojení RPC mezi nimi. Podobně jako v příkladech s exekučními klienty výše, každý konsensuální klient má konfigurační příznak, který jako argument přijímá cestu k souboru s tokenem jwt. Ta musí být shodná s cestou k `jwtsecret` poskytnutou exekučnímu klientovi. + +Pokud plánujete provozovat validátora, ujistěte se, že jste přidali konfigurační příznak specifikující adresu Etherea příjemce poplatků. Zde se hromadí odměny v etheru pro vašeho validátora. Každý konsensuální klient má možnost, např. `--suggested-fee-recipient=0xabcd1`, která jako argument přijímá adresu Etherea. + +Při spouštění Beacon Node na testnetu můžete ušetřit značný čas synchronizace použitím veřejného koncového bodu pro [Checkpoint sync](https://notes.ethereum.org/@launchpad/checkpoint-sync). + +#### Spuštění konsensuálního klienta {#running-a-consensus-client} + +##### Spuštění Lighthouse + +Před spuštěním Lighthouse se dozvíte více o tom, jak jej nainstalovat a nakonfigurovat v [Lighthouse Booku](https://lighthouse-book.sigmaprime.io/installation.html). + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### Spuštění Lodestaru + +Nainstalujte software Lodestar kompilací nebo stažením obrazu Docker. Více se dozvíte v [dokumentaci](https://chainsafe.github.io/lodestar/) a v podrobnějším [průvodci nastavením](https://hackmd.io/@philknows/rk5cDvKmK). + +```sh +lodestar beacon \ + --dataDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Spuštění Nimbus + +Nimbus přichází s konsensuálním i exekučním klientem. Může být spuštěn na různých zařízeních, dokonce i s velmi skromným výpočetním výkonem. +Po [instalaci závislostí a samotného Nimbusu](https://nimbus.guide/quick-start.html) můžete spustit jeho konsensuálního klienta: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### Spuštění Prysm + +Prysm přichází se skriptem, který umožňuje snadnou automatickou instalaci. Podrobnosti naleznete v [dokumentaci Prysm](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/). + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### Spuštění Teku + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +Když se konsensuální klient připojí k exekučnímu klientovi, aby si přečetl depozitní kontrakt a identifikoval validátory, připojí se také k ostatním peerům Beacon Node a zahájí synchronizaci konsensuálních slotů od geneze. Jakmile Beacon Node dosáhne aktuální epochy, stane se Beacon API použitelné pro vaše validátory. Dozvíte se více o [Beacon Node API](https://eth2docs.vercel.app/). + +### Přidání validátorů {#adding-validators} + +Konsensuální klient slouží jako Beacon Node, ke kterému se validátoři připojují. Každý konsensuální klient má svůj vlastní software pro validátory, který je podrobně popsán v jeho příslušné dokumentaci. + +Provozování vlastního validátoru umožňuje sólo staking (solo staking), nejúčinnější metodu podpory sítě Etherea, která nevyžaduje důvěru. To však vyžaduje vklad ve výši 32 ETH. Chcete-li spustit validátora na vlastním uzlu s menší částkou, mohl by vás zajímat decentralizovaný pool s operátory uzlů bez oprávnění, jako je [Rocket Pool](https://rocketpool.net/node-operators). + +Nejjednodušší způsob, jak začít se stakingem a generováním klíčů validátora, je použít [testnet Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/), který vám umožní otestovat vaše nastavení [provozováním uzlů na Hoodi](https://notes.ethereum.org/@launchpad/hoodi). Až budete připraveni na Mainnet, můžete tyto kroky zopakovat pomocí [Mainnet Staking Launchpadu](https://launchpad.ethereum.org/). + +Podívejte se na [stránku o stakingu](/staking) pro přehled možností stakingu. + +### Používání uzlu {#using-the-node} + +Exekuční klienti nabízejí koncové body [RPC API](/developers/docs/apis/json-rpc/), které můžete použít k odesílání transakcí, interakci s chytrými kontrakty nebo jejich nasazení na síti Etherea různými způsoby: + +- Ručním voláním s vhodným protokolem (např. pomocí `curl`) +- Připojením poskytnuté konzole (např. `geth attach`) +- Implementací v aplikacích pomocí knihoven web3, např. [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) + +Různí klienti mají různé implementace koncových bodů RPC. Existuje však standardní JSON-RPC, který můžete použít s každým klientem. Pro přehled si přečtěte [dokumentaci JSON-RPC](/developers/docs/apis/json-rpc/). Aplikace, které potřebují informace ze sítě Etherea, mohou používat toto RPC. Například populární peněženka MetaMask vám umožňuje [připojit se k vlastnímu koncovému bodu RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), což má velké výhody v oblasti soukromí a bezpečnosti. + +Konsensuální klienti všichni vystavují [Beacon API](https://ethereum.github.io/beacon-APIs), které lze použít ke kontrole stavu konsensuálního klienta nebo ke stahování bloků a konsensuálních dat odesíláním požadavků pomocí nástrojů, jako je [Curl](https://curl.se). Více informací o tomto naleznete v dokumentaci pro každý konsensuální klient. + +#### Dosažení RPC {#reaching-rpc} + +Výchozí port pro JSON-RPC exekučního klienta je `8545`, ale porty lokálních koncových bodů můžete v konfiguraci upravit. Ve výchozím nastavení je rozhraní RPC dostupné pouze na localhostu vašeho počítače. Chcete-li jej zpřístupnit vzdáleně, můžete jej vystavit veřejnosti změnou adresy na `0.0.0.0`. Tím se stane dostupným přes lokální síť a veřejné IP adresy. Ve většině případů budete také muset nastavit přesměrování portů na vašem routeru. + +K vystavování portů na internet přistupujte opatrně, protože to umožní komukoli na internetu ovládat váš uzel. Zlomyslní aktéři by mohli získat přístup k vašemu uzlu, aby shodili váš systém nebo ukradli vaše prostředky, pokud používáte svého klienta jako peněženku. + +Jedním ze způsobů, jak se tomu vyhnout, je zabránit modifikaci potenciálně škodlivých metod RPC. Například s Geth můžete deklarovat modifikovatelné metody pomocí příznaku: `--http.api web3,eth,txpool`. + +Přístup k rozhraní RPC lze rozšířit vývojem API na okrajové vrstvě nebo aplikací webového serveru, jako je Nginx, a jejich připojením k lokální adrese a portu vašeho klienta. Využití mezivrstvy může také vývojářům umožnit nastavit certifikát pro zabezpečené `https` připojení k rozhraní RPC. + +Nastavení webového serveru, proxy nebo externě orientovaného Rest API není jediný způsob, jak poskytnout přístup k koncovému bodu RPC vašeho uzlu. Dalším způsobem, jak nastavit veřejně dostupný koncový bod se zachováním soukromí, je hostovat uzel na vaší vlastní službě onion [Tor](https://www.torproject.org/). To vám umožní dosáhnout RPC mimo vaši lokální síť bez statické veřejné IP adresy nebo otevřených portů. Použití této konfigurace však může umožnit přístup k koncovému bodu RPC pouze přes síť Tor, kterou nepodporují všechny aplikace a může to vést k problémům s připojením. + +K tomu si musíte vytvořit vlastní [službu onion](https://community.torproject.org/onion-services/). Podívejte se na [dokumentaci](https://community.torproject.org/onion-services/setup/) o nastavení služby onion pro hostování vaší vlastní. Můžete ji nasměrovat na webový server s proxy na port RPC nebo přímo na RPC. + +A konečně, jedním z nejpopulárnějších způsobů poskytování přístupu k interním sítím je připojení VPN. V závislosti na vašem případu použití a počtu uživatelů, kteří potřebují přístup k vašemu uzlu, může být bezpečná VPN připojení volbou. [OpenVPN](https://openvpn.net/) je plně funkční SSL VPN, která implementuje zabezpečené rozšíření sítě na 2. nebo 3. vrstvě OSI pomocí standardního protokolu SSL/TLS, podporuje flexibilní metody ověřování klientů na základě certifikátů, čipových karet a/nebo přihlašovacích údajů s uživatelským jménem/heslem a umožňuje zásady řízení přístupu specifické pro uživatele nebo skupiny pomocí pravidel firewallu aplikovaných na virtuální rozhraní VPN. + +### Provozování uzlu {#operating-the-node} + +Měli byste pravidelně monitorovat svůj uzel, abyste se ujistili, že funguje správně. Možná budete muset provádět občasnou údržbu. + +#### Udržování uzlu online {#keeping-node-online} + +Váš uzel nemusí být online neustále, ale měli byste ho udržovat online co nejvíce, aby zůstal v synchronizaci se sítí. Můžete jej vypnout, abyste jej restartovali, ale mějte na paměti, že: + +- Vypnutí může trvat několik minut, pokud se poslední stav stále zapisuje na disk. +- Nucené vypnutí může poškodit databázi, což vyžaduje resynchronizaci celého uzlu. +- Váš klient se dostane mimo synchronizaci se sítí a bude se muset při restartu znovu synchronizovat. I když uzel může začít synchronizovat od místa, kde byl naposledy vypnut, proces může trvat určitou dobu v závislosti na tom, jak dlouho byl offline. + +_Toto se nevztahuje na uzly validátorů konsensuální vrstvy._ Vypnutí vašeho uzlu ovlivní všechny služby na něm závislé. Pokud provozujete uzel pro účely _stakování_, měli byste se snažit minimalizovat prostoje co nejvíce. + +#### Vytváření služeb klienta {#creating-client-services} + +Zvažte vytvoření služby pro automatické spouštění vašich klientů při startu. Například na serverech s Linuxem by dobrou praxí bylo vytvořit službu, např. s `systemd`, která spouští klienta se správnou konfigurací, pod uživatelem s omezenými oprávněními a automaticky se restartuje. + +#### Aktualizace klientů {#updating-clients} + +Musíte udržovat svůj software klienta aktuální s nejnovějšími bezpečnostními záplatami, funkcemi a [EIP](/eips/). Zejména před [hard forky](/ethereum-forks/) se ujistěte, že používáte správné verze klienta. + +> Před důležitými aktualizacemi sítě EF zveřejňuje příspěvek na svém [blogu](https://blog.ethereum.org). Můžete se [přihlásit k odběru těchto oznámení](https://blog.ethereum.org/category/protocol#subscribe), abyste dostali upozornění na váš e-mail, když váš uzel potřebuje aktualizaci. + +Aktualizace klientů je velmi jednoduchá. Každý klient má ve své dokumentaci specifické pokyny, ale proces je obecně jen stažení nejnovější verze a restartování klienta s novým spustitelným souborem. Klient by měl pokračovat tam, kde skončil, ale s aplikovanými aktualizacemi. + +Každá implementace klienta má lidsky čitelný řetězec verze, který se používá v protokolu peer-to-peer, ale je také přístupný z příkazového řádku. Tento řetězec verze umožňuje uživatelům zkontrolovat, zda používají správnou verzi, a umožňuje prohlížečům bloků a dalším analytickým nástrojům, které se zajímají o kvantifikaci distribuce konkrétních klientů v síti. Pro více informací o řetězcích verzí se prosím obraťte na dokumentaci jednotlivých klientů. + +#### Provozování dalších služeb {#running-additional-services} + +Provozování vlastního uzlu vám umožňuje používat služby, které vyžadují přímý přístup k RPC klienta Etherea. Jedná se o služby postavené na Ethereu, jako jsou [řešení vrstvy 2](/developers/docs/scaling/#layer-2-scaling), backend pro peněženky, prohlížeče bloků, vývojářské nástroje a další infrastruktura Etherea. + +#### Monitorování uzlu {#monitoring-the-node} + +Chcete-li správně monitorovat svůj uzel, zvažte sběr metrik. Klienti poskytují koncové body pro metriky, takže můžete získat komplexní data o svém uzlu. Použijte nástroje jako [InfluxDB](https://www.influxdata.com/get-influxdb/) nebo [Prometheus](https://prometheus.io/) k vytvoření databází, které můžete přeměnit na vizualizace a grafy v softwaru jako [Grafana](https://grafana.com/). Existuje mnoho nastavení pro použití tohoto softwaru a různé řídicí panely Grafana pro vizualizaci vašeho uzlu a celé sítě. Například se podívejte na [návod na monitorování Gethu](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/). + +V rámci monitorování se ujistěte, že sledujete výkon vašeho stroje. Během počáteční synchronizace vašeho uzlu může být software klienta velmi náročný na CPU a RAM. Kromě Grafany můžete k tomu použít nástroje, které nabízí váš operační systém, jako `htop` nebo `uptime`. + +## Další čtení {#further-reading} + +- [Ethereum Staking Guides](https://github.com/SomerEsat/ethereum-staking-guides) – _Somer Esat, často aktualizováno_ +- [Průvodce | Jak nastavit validátor pro staking na mainnetu Etherea](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, často aktualizováno_ +- [Průvodci ETHStaker k provozování validátorů na testnetech](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, pravidelně aktualizováno_ +- [Ukázková aplikace AWS Blockchain Node Runner pro uzly Etherea](https://aws-samples.github.io/aws-blockchain-node-runners/docs/Blueprints/Ethereum) – _AWS, často aktualizováno_ +- [Časté dotazy ke Sloučení pro operátory uzlů](https://notes.ethereum.org/@launchpad/node-faq-merge) – _červenec 2022_ +- [Analýza hardwarových požadavků pro plně validovaný uzel Etherea](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 24. září 2018_ +- [Provozování plných uzlů Ethereum: Příručka pro sotva motivované](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 7. listopadu 2019_ +- [Spuštění uzlu Hyperledger Besu na mainnetu Etherea: Výhody, požadavky a nastavení](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi, 7. května 2020_ +- [Nasazení klienta Nethermind Ethereum s monitorovacím balíčkem](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 8. července 2020_ + +## Související témata {#related-topics} + +- [Uzly a klienti](/developers/docs/nodes-and-clients/) +- [Bloky](/developers/docs/blocks/) +- [Sítě](/developers/docs/networks/) diff --git a/public/content/translations/cs/developers/docs/oracles/index.md b/public/content/translations/cs/developers/docs/oracles/index.md new file mode 100644 index 00000000000..974b3af2d04 --- /dev/null +++ b/public/content/translations/cs/developers/docs/oracles/index.md @@ -0,0 +1,433 @@ +--- +title: Data oracle +description: "Orákula poskytují smart kontraktům na Ethereu přístup k reálným datům, čímž otevírají nové způsoby použití a přinášejí větší hodnotu pro uživatele." +lang: cs +--- + +Oracles jsou aplikace, které vytvářejí datové kanály, jež zpřístupňují blockchainu pro smart kontrakty offchainové datové zdroje. To je nezbytné, protože smart kontrakty založené na Ethereu nemohou ve výchozím nastavení přistupovat k informacím uloženým mimo blockchainovou síť. + +Poskytnutí možnosti smart kontraktům provádět operace s využitím offchainových dat rozšiřuje užitečnost a hodnotu decentralizovaných aplikací. Například onchainové predikční trhy se spoléhají na oracles, které jim poskytují informace o výsledcích, jež používají k ověření předpovědí uživatelů. Představme si, že Alice vsadí 20 ETH na to, kdo se stane příštím prezidentem USA. V takovém případě bude predikční aplikace potřebovat orákulum, které potvrdí výsledky voleb a určilí, zda má Alice nárok na výplatu. + +## Předpoklady {#prerequisites} + +Tato stránka předpokládá, že je čtenář obeznámen se základy Etherea, včetně [uzlů](/developers/docs/nodes-and-clients/), [mechanismů konsenzu](/developers/docs/consensus-mechanisms/) a [EVM](/developers/docs/evm/). Měli byste také dobře rozumět [smart kontraktům](/developers/docs/smart-contracts/) a [anatomii smart kontraktů](/developers/docs/smart-contracts/anatomy/), zejména [událostem](/glossary/#events). + +## Co je blockchainové orákulum? Co je to blockchain oracle? {#what-is-a-blockchain-oracle} + +Oracles jsou aplikace, které získávají, ověřují a přenášejí externí informace (tj. informace uložené mimo blockchain) do smart kontraktů běžících na blockchainu. Kromě „tahání“ offchainových dat a jejich vysílání na Ethereu mohou oracles také „tlačit“ informace z blockchainu do externích systémů, např. odemknutí chytrého zámku, jakmile uživatel odešle poplatek prostřednictvím transakce na Ethereu. + +Bez oraclu by byl smart kontrakt zcela omezen na onchainová data. + +Orákula se liší podle zdroje dat (jeden nebo více zdrojů), modelů důvěry (centralizované nebo decentralizované) a systémové architektury (okamžité čtení, publikování-odběr a žádost-odpověď). Oracles můžeme také rozlišovat podle toho, zda získávají externí data pro použití onchainovými kontrakty (vstupní oracles), posílají informace z blockchainu do offchainových aplikací (výstupní oracles), nebo provádějí výpočetní úlohy offchain (výpočetní oracles). + +## Proč smart kontrakty potřebují orákula? {#why-do-smart-contracts-need-oracles} + +Mnoho vývojářů vidí smart kontrakty jako kód běžící na specifických adresách na blockchainu. Obecnější [pohled na smart kontrakty](/smart-contracts/) je však takový, že se jedná o samočinně se provádějící softwarové programy, které jsou schopny vynucovat dohody mezi stranami, jakmile jsou splněny určité podmínky – odtud pochází termín „smart kontrakty“. + +Použití smart kontraktů k vynucování dohod mezi lidmi však není jednoduché, vzhledem k tomu, že Ethereum je deterministické. [Deterministický systém](https://en.wikipedia.org/wiki/Deterministic_algorithm) je takový systém, který při daném počátečním stavu a konkrétním vstupu vždy produkuje stejné výsledky, což znamená, že v procesu výpočtu výstupů ze vstupů není žiadna náhodnost ani variace. + +Pro dosažení deterministického provádění omezují blockchainy uzly na dosažení konsenzu u jednoduchých binárních otázek (pravda/nepravda) s použitím _pouze_ dat uložených na samotném blockchainu. Příklady takových otázek zahrnují: + +- „Podepsal vlastník účtu (identifikovaný veřejným klíčem) tuto transakci přidruženým privátním klíčem?“ +- „Má tento účet dostatek prostředků na pokrytí transakce?“ +- „Je tato transakce platná v kontextu tohoto smart kontraktu?“ atd. + +Pokud by blockchainy dostávaly informace z externích zdrojů (tj. z reálného světa), nebylo by možné dosáhnout determinismu, což by bránilo uzlům dohodnout se na platnosti změn stavu blockchainu. Vezměme si například smart kontrakt, který provádí transakci na základě aktuálního směnného kurzu ETH/USD získaného z tradičního cenového API. Tato hodnota se pravděpodobně bude často měnit (nemluvě o tom, že API může být zrušeno nebo napadeno), což znamená, že síťové uzly provádějící stejný kód kontraktu by dospěly k různým výsledkům. + +U veřejného blockchainu, jako je Ethereum, kde tisíce síťových uzlů po celém světě zpracovávají transakce, je determinismus klíčový. Bez centrální autority, která by sloužila jako zdroj pravdy, potřebují tyto uzly mechanismy, které jim umožní dosáhnout stejného stavu po aplikaci stejných transakcí. Pokud by uzel A vykonal kód smart kontraktu a dosáhl výsledku "3", zatímco uzel B by při provedení stejné transakce dosáhl výsledku "7", došlo by k narušení konsensu a Ethereum by ztratilo svou hodnotu jako decentralizovaná výpočetní platforma. + +Tento scénář také zdůrazňuje problém s navrhováním blockchainů tak, aby získávaly informace z externích zdrojů. Oracles však tento problém řeší tak, že berou informace z offchainových zdrojů a ukládají je na blockchain, aby je mohly smart kontrakty využívat. Protože informace uložené onchain jsou neměnné a veřejně dostupné, mohou uzly Etherea bezpečně používat offchainová data importovaná oraclem k výpočtu změn stavu bez narušení konsenzu. + +Za tímto účelem se oracle obvykle skládá ze smart kontraktu běžícího onchain a některých offchainových komponent. Onchainový kontrakt přijímá požadavky na data od jiných smart kontraktů, které předává offchainové komponentě (nazývané uzel oraclu). Tento orákulový uzel může dotazovat zdroje dat – například pomocí aplikačních programových rozhraní (API) – a zasílat transakce pro uložení požadovaných dat do úložiště smart kontraktu. + +Orákulum v podstatě překlenuje informační propast mezi blockchainem a externím prostředím a vytváří „hybridní smart kontrakty“. Hybridní smart kontrakt je takový, který funguje na základě kombinace kódu onchainového kontraktu a offchainové infrastruktury. Decentralizované predikční trhy jsou vynikajícím příkladem hybridních smart kontraktů. Dalšími příklady mohou být smart kontrakty určené k pojištění plodin, které vyplácejí pojistné plnění, když určitá orákula určí, že došlo k určitému meteorologickému jevu. + +## Jaké problémy se s orákuly pojí? Problém oracles {#the-oracle-problem} + +Orákula řeší důležitý problém, ale zároveň přinášejí některé komplikace, např.,: + +- Jak ověříme, že zadané informace byly získány ze správného zdroje nebo že nebyly pozměněny? + +- Jak zajistíme, že tato data budou vždy dostupná a pravidelně aktualizovaná? + +Takzvané „problémy orákulí“ poukazuje na problémy spojené s používáním blockchainových orákul k zasílání vstupů do smart kontraktů. Data z orákula musí být správná, aby mohl smart kontrakt správně fungovat. Navíc nutnost „důvěřovat“ operátorům orákul, že poskytují přesné informace, podkopává „bezpečnost bez nutnosti důvěry“, kterou smart kontrakty slibují. + +Různá orákula nabízejí různé způsoby řešení problému orákulí, které prozkoumáme později. Orákula jsou obvykle hodnocena na základě toho, jak dobře zvládají následující výzvy: + +1. **Správnost**: Oracle by neměl způsobovat, aby smart kontrakty spouštěly změny stavu na základě neplatných offchainových dat. Oracle musí zaručit _pravost_ a _integritu_ dat. Pravost znamená, že data byla získána ze správného zdroje, zatímco integrita znamená, že data zůstala nedotčena (tj. nebyla změněna) před odesláním onchain. + +2. **Dostupnost**: Oracle by neměl zdržovat nebo bránit smart kontraktům v provádění akcí a spouštění změn stavu. To znamená, že data z oraclu musí být _dostupná na vyžádání_ bez přerušení. + +3. **Kompatibilita pobídek**: Oracle by měl motivovat offchainové poskytovatele dat k předkládání správných informací smart kontraktům. Kompatibilita pobídek zahrnuje _přiřaditelnost_ a _odpovědnost_. Možnost přiřazení umožňuje spojit externí informaci s jejím poskytovatelem, zatímco odpovědnost váže poskytovatele dat k informacím, které poskytují, aby mohli být odměněni nebo potrestáni na základě kvality poskytnutých informací. + +## Jak funguje služba blockchainového orákula? Jak funguje služba blockchain oracle? {#how-does-a-blockchain-oracle-service-work} + +### Uživatelé {#users} + +Uživatelé jsou entity (tj. smart kontrakty), které potřebují informace mimo blockchain k dokončení konkrétních akcí. Základní pracovní postup služby orákula začíná tím, že uživatel odešle požadavek na data do orákulového kontraktu. Požadavky na data obvykle odpovídají na některé nebo všechny následující otázky: + +1. Z jakých zdrojů mohou offchainové uzly čerpat požadované informace? + +2. Jak reportující entity zpracovávají informace ze zdrojů dat a extrahují užitečné datové body? + +3. Kolik orákulových uzlů se může podílet na získávání dat? + +4. Jak by měly být řešeny nesrovnalosti v orákulových reportech? + +5. Jakou metodou by mělo být implementováno filtrování příspěvků a agregace zpráv do jedné hodnoty? + +### Kontrakt oraclu {#oracle-contract} + +Kontrakt oraclu je onchainová komponenta služby oraclu. Naslouchá požadavkům na data od jiných kontraktů, předává dotazy na data orákulovým uzlům a vysílá vrácená data do klientských kontraktů. Tento kontrakt může také provádět určité výpočty na vrácených datových bodech, aby vytvořil agregovanou hodnotu, kterou odešle požadujícímu kontraktu. + +Orákulový kontrakt poskytuje některé funkce, které klientské kontrakty volají během podání požadavku na data. Po obdržení nového dotazu smart kontrakt vyšle [událost protokolu](/developers/docs/smart-contracts/anatomy/#events-and-logs) s podrobnostmi o požadavku na data. Tím se upozorní offchainové uzly, které jsou přihlášeny k odběru protokolu (obvykle pomocí příkazu JSON-RPC `eth_subscribe`), a ty následně přistoupí k získání dat definovaných v události protokolu. + +Níže je uveden [příklad kontraktu oraclu](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) od Pedra Costy. Jedná se o jednoduchou službu oraclu, která se na žádost jiných smart kontraktů může dotazovat offchainových API a ukládat požadované informace na blockchain: + +```solidity +pragma solidity >=0.4.21 <0.6.0; + +contract Oracle { + Request[] requests; //seznam požadavků zadaných kontraktu + uint currentId = 0; //inkrementální ID požadavku + uint minQuorum = 2; //minimální počet odpovědí, které je třeba obdržet před vyhlášením konečného výsledku + uint totalOracleCount = 3; // napevno zakódovaný počet oraclů + + // definuje obecný požadavek na API + struct Request { + uint id; //ID požadavku + string urlToQuery; //URL adresa API + string attributeToFetch; //atribut JSON (klíč), který se má získat v odpovědi + string agreedValue; //hodnota z klíče + mapping(uint => string) answers; //odpovědi poskytnuté oracly + mapping(address => uint) quorum; //oracles, které se budou dotazovat na odpověď (1=oracle nehlasoval, 2=oracle hlasoval) + } + + //událost, která spouští oracle mimo blockchain + event NewRequest ( + uint id, + string urlToQuery, + string attributeToFetch + ); + + //spustí se, když dojde ke konsenzu o konečném výsledku + event UpdatedRequest ( + uint id, + string urlToQuery, + string attributeToFetch, + string agreedValue + ); + + function createRequest ( + string memory _urlToQuery, + string memory _attributeToFetch + ) + public + { + uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); + Request storage r = requests[length-1]; + + // napevno zakódovaná adresa oraclů + r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; + r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; + r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; + + // spustit událost, kterou zjistí oracle mimo blockchain + emit NewRequest ( + currentId, + _urlToQuery, + _attributeToFetch + ); + + // zvýšit ID požadavku + currentId++; + } + + //voláno oraclem pro záznam jeho odpovědi + function updateRequest ( + uint _id, + string memory _valueRetrieved + ) public { + + Request storage currRequest = requests[_id]; + + //zkontrolovat, zda je oracle v seznamu důvěryhodných oraclů + //a zda oracle ještě nehlasoval + if(currRequest.quorum[address(msg.sender)] == 1){ + + //označení, že tato adresa hlasovala + currRequest.quorum[msg.sender] = 2; + + //procházet „pole“ odpovědí, dokud není pozice volná, a uložit načtenou hodnotu + uint tmpI = 0; + bool found = false; + while(!found) { + //najít první prázdné místo + if(bytes(currRequest.answers[tmpI]).length == 0){ + found = true; + currRequest.answers[tmpI] = _valueRetrieved; + } + tmpI++; + } + + uint currentQuorum = 0; + + //procházet seznamem oraclů a zkontrolovat, zda dostatek oraclů (minimální kvorum) + //hlasovalo pro stejnou odpověď jako je ta současná + for(uint i = 0; i < totalOracleCount; i++){ + bytes memory a = bytes(currRequest.answers[i]); + bytes memory b = bytes(_valueRetrieved); + + if(keccak256(a) == keccak256(b)){ + currentQuorum++; + if(currentQuorum >= minQuorum){ + currRequest.agreedValue = _valueRetrieved; + emit UpdatedRequest ( + currRequest.id, + currRequest.urlToQuery, + currRequest.attributeToFetch, + currRequest.agreedValue + ); + } + } + } + } + } +} +``` + +### Uzly oraclu {#oracle-nodes} + +Uzel oraclu je offchainová komponenta služby oraclu. Získává informace z externích zdrojů, jako jsou API hostované на serverech třetích stran, a ukládá je onchain pro využití smart kontrakty. Uzly oraclu naslouchají událostem z onchainového kontraktu oraclu a přistupují k dokončení úkolu popsaného v protokolu. + +Běžným úkolem uzlů oraclu je odeslání požadavku [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) službě API, parsování odpovědi za účelem extrakce relevantních dat, jejich formátování do výstupu čitelného pro blockchain a odeslání onchain zahrnutím do transakce do kontraktu oraclu. Orákulový uzel může být také povinen potvrdit platnost a integritu předkládaných informací pomocí „důkazů autenticity“, které prozkoumáme později. + +Výpočetní oracles se také spoléhají na offchainové uzly při provádění výpočetních úloh, které by bylo nepraktické provádět onchain, vzhledem k nákladům na gas a limitům velikosti bloku. Například orákulový uzel může být pověřen generováním ověřitelně náhodného čísla (např. pro hry založené na blockchainu). + +## Návrhové vzory oraclů {#oracle-design-patterns} + +Oracles se vyskytují v různých typech, včetně _okamžitého čtení_, _publikování-odběru_ a _požadavku-odpovědi_, přičemž poslední dva jsou nejoblíbenější mezi smart kontrakty na Ethereu. V následujících odstavcích krátce popíšeme modely "publikování-odběr" a "žádost-odpověď". + +### Oracles typu publikování-odběr {#publish-subscribe-oracles} + +Tento typ orákula poskytuje "datový kanál", který mohou ostatní kontrakty pravidelně číst za účelem získání informací. Data v tomto případě často podléhají změnám, takže klientské kontrakty musí sledovat aktualizace dat v úložišti orákula. Příkladem je orákulum, které uživatelům poskytuje nejnovější informace o ceně ETH/USD. + +### Oracles typu požadavek-odpověď {#request-response-oracles} + +Nastavení "žádost-odpověď" umožňuje klientskému kontraktu požadovat libovolná data jiná než ta, která poskytuje orákulum typu "publikování-odběr". Orákula typu žádost-odpověď jsou ideální, když je dataset příliš velký na to, aby byl uchováván v úložišti smart kontraktu, a nebo když uživatelé potřebují v daném okamžiku pouze malou část dat. + +Ačkoli jsou složitější než modely "publikování-odběr", orákula typu žádost-odpověď v zásadě fungují tak, jak jsme popsali v předchozí sekci. Oracle bude mít onchainovou komponentu, která přijímá požadavek na data a předává ho ke zpracování offchainovému uzlu. + +Uživatelé, kteří iniciují datové dotazy, musí uhradit náklady na získání informací z offchainového zdroje. Klientský kontrakt musí také poskytnout prostředky na pokrytí palivových nákladů, které vzniknou orákulovému kontraktu při vrácení odpovědi prostřednictvím funkce callback, která je specifikována v požadavku. + +## Centralizované vs. decentralizované oracles {#types-of-oracles} + +### Centralizované oracles {#centralized-oracles} + +Centralizovaný oracle je řízen jedinou entitou, která je zodpovědná za agregaci offchainových informací a aktualizaci dat kontraktu oraclu podle požadavků. Centralizovaná orákula jsou efektivní, protože se spoléhají na jediný zdroj pravdy. Mohou lépe fungovat v případech, kdy jsou proprietární datové sady publikovány přímo vlastníkem s široce akceptovaným podpisem. Nicméně, přinášejí i nevýhody: + +#### Nízké záruky správnosti {#low-correctness-guarantees} + +U centralizovaných orákul neexistuje způsob, jak ověřit, zda jsou poskytnuté informace správné či nikoliv. I "důvěryhodní" poskytovatelé se mohou stát nedůvěryhodnými nebo mohou být hacknuti. Pokud se orákulum nechá zkorumpovat, smart kontrakty budou vykonávat činnosti na základě špatných dat. + +#### Špatná dostupnost {#poor-availability} + +U centralizovaných oraclů není zaručeno, že budou offchainová data vždy dostupná ostatním smart kontraktům. Pokud se poskytovatel rozhodne službu vypnout nebo hacker unese offchainovou komponentu oraclu, je váš smart kontrakt vystaven riziku útoku typu DoS (denial of service). + +#### Špatná kompatibilita pobídek {#poor-incentive-compatibility} + +Centralizovaná orákula často nemají dobře navržené motivace (případně nemajjí vůbec žádné motivace) pro poskytovatele dat, nemohou tak zaručit, že jim budou zasílat přesné a nepozměněné informace. Platba za správnost orákula nezaručuje jeho poctivost. Tento problém se zhoršuje, jakmile se zvýší hodnota, kterou smart kontrakty spravují. + +### Decentralizované oracles {#decentralized-oracles} + +Decentralizovaná orákula jsou navržena tak, aby překonala omezení centralizovaných orákul odstraněním tzv. jediného bodu selhání. Decentralizovaná služba oraclu se skládá z více účastníků v peer-to-peer síti, kteří dosáhnou konsenzu ohledně offchainových dat před jejich odesláním do smart kontraktu. + +Decentralizované orákulum by mělo být (ideálně) bez nutnosti povolení, důvěryhodné a bez nutnosti správy centrální stranou; ve skutečnosti je však decentralizace mezi orákuly spektrální. Existují polodecentralizované sítě orákulí, do kterých se může zapojit kdokoliv, ale s „vlastníkem“, který schvaluje a odstraňuje uzly na základě historické výkonnosti. Existují také plně decentralizované orákulové sítě: Ty obvykle fungují jako samostatné blockchainy a mají definované konsensuální mechanismy pro koordinaci uzlů a postihů za špatného chování. + +Používání decentralizovaných orákul přináší následující výhody: + +### Vysoké záruky správnosti {#high-correctness-guarantees} + +Decentralizovaná orákula se snaží zajistit správnost dat pomocí různých přístupů. To zahrnuje použití důkazů potvrzujících pravost a integritu vrácených informací a požadavek, aby se více entit kolektivně shodlo na platnosti offchainových dat. + +#### Důkazy pravosti {#authenticity-proofs} + +Důkazy autenticity jsou kryptografické mechanismy, které umožňují nezávislé ověření informací získaných z externích zdrojů. Tyto důkazy mohou ověřit zdroj informací a odhalit možné změny provedené v datech poté, co byla obdržena. + +Příklady důkazů autenticity zahrnují: + +**Důkazy Transport Layer Security (TLS)**: Uzly oraclu často získávají data z externích zdrojů pomocí zabezpečeného připojení HTTP založeného na protokolu Transport Layer Security (TLS). Některá decentralizovaná orákula používají důkazy autenticity k ověření TLS akce (tj. potvrzení výměny informací mezi uzlem a konkrétním serverem) a potvrzení, že obsah akce nebyl změněn. + +**Atestace důvěryhodného prostředí pro provádění (TEE)**: [Důvěryhodné prostředí pro provádění](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) je sandboxové výpočetní prostředí, které je izolováno od provozních procesů svého hostitelského systému. TEE zajišťuje, že jakýkoliv aplikační kód nebo data uložená či používaná ve výpočetním prostředí si zachovávají integritu, důvěrnost a neměnnost. Uživatelé mohou také generovat ověření, aby dokázali, že instance aplikace běží v důvěryhodném výpočetním prostředí. + +Některé třídy decentralizovaných orákul vyžadují, aby provozovatelé orákulových uzlů poskytovali TEE ověření. To uživateli potvrzuje, že provozovatel uzlu spouští instanci orákulového klienta v důvěryhodném výpočetním prostředí. TEE zabraňují externím procesům měnit nebo číst kód a data aplikace, a proto tato ověření dokazují, že orákulový uzel zachoval informace neporušené a důvěrné. + +#### Ověřování informací na základě konsenzu {#consensus-based-validation-of-information} + +Centralizovaná orákula se spoléhají na jeden zdroj pravdy při poskytování dat smart kontraktům, což přináší možnost publikace nepřesných informací. Decentralizované oracles řeší tento problém tím, že se spoléhají na více uzlů oraclu, které se dotazují na offchainové informace. Porovnáváním dat z více zdrojů snižují decentralizované oracles riziko předání neplatných informací onchainovým kontraktům. + +Decentralizované oracles se však musí vypořádat s nesrovnalostmi v informacích získaných z více offchainových zdrojů. Aby se minimalizovaly rozdíly v informacích a zajistilo se, že data předaná orákulovému kontraktu odrážejí kolektivní názor orákulových uzlů, používají decentralizovaná orákula následující mechanismy: + +##### Hlasování nebo staking sloužící k potvrzení správnosti dat + +Některé decentralizované orákulové sítě vyžadují, aby účastníci hlasovali nebo aby na důkaz správnosti odpovědí na dotazy (např. „Kdo vyhrál americké volby v roce 2020?“) zastakovali své prostředky pomocí nativního tokenu sítě. Agregační protokol poté sdruží hlasy a zastakovaný kolaterál a odpověď podporovanou většinou bere jako platnou. + +Uzlům, jejichž odpovědi se odchylují od většinové odpovědi, jsou jejich tokeny odebrány a dále se rozdělí těm, kteří poskytli správnější hodnoty. Nutnost poskytnout kolaterál před odesláním dat je motivací k poctivým odpovědím, protože se předpokládá, že uzly jednají jako racionální ekonomičtí aktéři s úmyslem maximalizovat své výnosy. + +Stakování/hlasování také chrání decentralizované oracles před [útoky Sybil](/glossary/#sybil-attack), kdy škodliví aktéři vytvářejí více identit, aby manipulovali se systémem konsenzu. Nicméně staking nemůže zabránit „parazitování“ (kdy orákulové uzly kopírují informace od ostatních) a „línému ověřování“ (kdy orákulové uzly následují většinu bez vlastního ověření informací). + +##### Mechanismy Schellingova bodu + +[Schelling point](https://en.wikipedia.org/wiki/Focal_point_\(game_theory\)) je koncept z teorie her, který předpokládá, že více entit bude v nepřítomnosti jakékoli komunikace vždy inklinovat ke společnému řešení problému. Mechanismy Schellingova bodu se často používají v decentralizovaných orákulových sítích, aby v odpovědích na dotazy umožnily uzlům dosáhnout shody. + +Ranou myšlenkou byl [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), navrhovaný datový kanál, kde účastníci zasílají odpovědi na „skalární“ otázky (otázky, jejichž odpovědi jsou popsány velikostí, např. „jaká je cena ETH?“) spolu s vkladem. Uživatelé, kteří poskytnou hodnoty mezi 25. a 75. [percentilem](https://en.wikipedia.org/wiki/Percentile), jsou odměněni, zatímco ti, jejichž hodnoty se výrazně odchylují od mediánu, jsou penalizováni. + +Ačkoli SchellingCoin dnes neexistuje, řada decentralizovaných oraclů – zejména [oracly protokolu Maker](https://docs.makerdao.com/smart-contract-modules/oracle-module) – používá mechanismus Schelling point ke zlepšení přesnosti dat oraclu. Každý Maker Oracle se skládá z offchainové P2P sítě uzlů („relayers“ a „feeds“), které předkládají tržní ceny kolaterálových aktiv, a onchainového kontraktu „Medianizer“, který vypočítá medián všech poskytnutých hodnot. Jakmile uplyne stanovená doba zpoždění, tato mediánová hodnota se stává novou referenční cenou daného aktiva. + +Dalšími příklady oraclů, které používají mechanismy Schelling point, jsou [Chainlink Offchain Reporting](https://docs.chain.link/architecture-overview/off-chain-reporting) a [Witnet](https://witnet.io/). V obou systémech jsou odpovědi z orákulových uzlů v peer-to-peer síti agregovány do jedné agregované hodnoty, jako je průměr nebo medián. Uzly jsou odměněny nebo penalizovány v závislosti na tom, do jaké míry se jejich odpovědi shodují a nebo jak moc se odchylují od agregované hodnoty. + +Mechanismy Schelling point jsou atraktivní, protože minimalizují onchainovou stopu (je třeba odeslat pouze jednu transakci) a zároveň zaručují decentralizaci. To je možné díky tomu, že uzly musí podepsat seznam předložených odpovědí, než je tento seznam předán algoritmu, který vypočítá průměrnou či mediánovou hodnotu. + +### Dostupnost {#availability} + +Decentralizované služby oraclů zajišťují vysokou dostupnost offchainových dat pro smart kontrakty. Toho je dosaženo decentralizací jak zdroje offchainových informací, tak uzlů odpovědných za přenos informací onchain. + +Tím je zajišťema odolnost proti chybám, protože orákulový kontrakt se při plnění dotazů z jiných kontraktů může spolehnout na více uzlů (které se také spoléhají na více zdrojů dat). Decentralizace na úrovni zdroje _a_ operátorů uzlů je klíčová – síť uzlů oraclu poskytujících informace získané ze stejného zdroje se dostane do stejného problému jako centralizovaný oracle. + +Je také možné, aby oracly založené na stakování trestaly operátory uzlů, kteří na požadavky o data nereagují dostatečně rychle. To výrazně motivuje orákulové uzly investovat do infrastruktury odolné proti chybám a poskytovat data včas. + +### Dobrá kompatibilita pobídek {#good-incentive-compatibility} + +Decentralizované oracles implementují různé návrhy pobídek, aby zabránily [byzantskému](https://en.wikipedia.org/wiki/Byzantine_fault) chování mezi uzly oraclu. Konkrétně dosahují _přiřaditelnosti_ a _odpovědnosti_: + +1. Decentralizované orákulové uzly mají často povinnost podepisovat data, která poskytují v odpovědi na dotazy na data. Tyto informace pomáhají s hodnocením historického výkonu orákulových uzlů, takže uživatelé mohou při zadávání dotazů na data vyloučit nespolehlivé orákulové uzly. Příkladem je [algoritmický reputační systém](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system) od Witnet. + +2. Decentralizovaná orákula - jak bylo vysvětleno dříve - mohou vyžadovat, aby uzly vložily kolaterál jako potvrzení důvěry v pravdivost dat, která předkládají. Pokud se ukáže, že jsou data správná, může být tento kolaterál vrácen společně s odměnami za poctivé služby. Pokud jsou však informace nesprávné, může být odebrán, což poskytuje určitý stupeň odpovědnosti. + +## Aplikace oraclů ve smart kontraktech {#applications-of-oracles-in-smart-contracts} + +Následující příklady jsou běžnými případy použití orákulí na Ethereu: + +### Získávání finančních dat {#retrieving-financial-data} + +Aplikace [decentralizovaného financování](/defi/) (DeFi) umožňují peer-to-peer půjčování, vypůjčování a obchodování s aktivy. To často vyžaduje různé finanční informace, včetně údajů o směnných kurzech (pro výpočet hodnoty kryptoměn ve fiat měnách nebo pro srovnávání cen tokenů) a údajů z kapitálových trhů (pro výpočet hodnoty tokenizovaných aktiv, jako je zlato nebo americký dolar). + +DeFi Protokol pro poskytování půjček se potřebuje dotazovat na aktuální tržní ceny aktiv (např. ETH) uložených jako kolaterál. To umožňuje kontraktu určit hodnotu kolateralizovaných aktiv a stanovit, kolik si může vypůjčit z tohoto systému. + +Populární „cenové oracles“ (jak se jim často říká) v DeFi zahrnují Chainlink Price Feeds, [Open Price Feed](https://compound.finance/docs/prices) od Compound Protocol, [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) od Uniswapu a [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module). + +Vývojáři by měli rozumět omezením, které s sebou tato cenová orákula nesou, než je integrují do svého projektu. Tento [článek](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) poskytuje podrobnou analýzu toho, co je třeba zvážit při plánování použití kteréhokoli ze zmíněných cenových oraclů. + +Níže uvádíme kód, pomocí kterého můžete ve svém smart kontraktu získat aktuální cenu ETH pomocí cenového kanálu od Chainlinku: + +```solidity +pragma solidity ^0.6.7; + +import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; + +contract PriceConsumerV3 { + + AggregatorV3Interface internal priceFeed; + + /** + * Síť: Kovan + * Agregátor: ETH/USD + * Adresa: 0x9326BFA02ADD2366b30bacB125260Af641031331 + */ + constructor() public { + priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); + } + + /** + * Vrátí nejnovější cenu + */ + function getLatestPrice() public view returns (int) { + ( + uint80 roundID, + int price, + uint startedAt, + uint timeStamp, + uint80 answeredInRound + ) = priceFeed.latestRoundData(); + return price; + } +} +``` + +### Generování ověřitelné náhodnosti {#generating-verifiable-randomness} + +Některé blockchainové aplikace, jako jsou blockchainové hry nebo loterie, vyžadují vysokou úroveň nepředvídatelnosti a náhodnosti, aby mohly efektivně fungovat. Deterministické provádění transakcí na blockchainu však eliminuje náhodnost. + +Původní přístup spočíval v použití pseudonáhodných kryptografických funkcí, jako je `blockhash`, ale ty mohly být [manipulovány těžaři](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) při řešení algoritmu proof-of-work. Přechod Etherea na [proof-of-stake](/roadmap/merge/) také znamená, že vývojáři se již nemohou spoléhat na `blockhash` pro onchainovou náhodnost. Mechanismus [RANDAO](https://eth2book.info/altair/part2/building_blocks/randomness) řetězce Beacon Chain místo toho poskytuje alternativní zdroj náhodnosti. + +Je možné generovat náhodnou hodnotu offchain a poslat ji onchain, ale to klade vysoké nároky na důvěru uživatelů. Musí věřit, že hodnota byla skutečně vygenerována nepředvídatelným způsobem a nebyla během přenosu změněna. + +Oracly určené pro offchainové výpočty řeší tento problém bezpečným generováním náhodných výsledků offchain, které vysílají onchain spolu s kryptografickými důkazy potvrzujícími nepředvídatelnost procesu. Příkladem je [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Verifiable Random Function), což je prokazatelně spravedlivý a proti neoprávněné manipulaci odolný generátor náhodných čísel (RNG), který je užitečný pro vytváření spolehlivých smart kontraktů pro aplikace, které se spoléhají na nepředvídatelné výsledky. + +### Získávání výsledků událostí {#getting-outcomes-for-events} + +S orákuly je snadné vytvářet smart kontrakty, které reagují na reálné události. Služby oraclů to umožňují tím, že kontraktům dovolují připojit se k externím API prostřednictvím offchainových komponent a využívat informace z těchto datových zdrojů. Například dříve zmíněná predikční dApp může požádat oracle, aby vrátil výsledky voleb z důvěryhodného offchainového zdroje (např. Associated Press). + +Použití orákul k získávání dat na základě reálných výsledků umožňuje další nové případy použití; například decentralizovaný pojišťovací produkt potřebuje přesné informace o počasí, katastrofách atd., aby mohl efektivně fungovat. + +### Automatizace smart kontraktů {#automating-smart-contracts} + +Smart kontrakty se nespouštějí automaticky; externě vlastněný účet (EOA) nebo jiný kontraktový účet musí za účelem spuštění smart kontraktu zavolat ty správné funkce. Ve většině případů jsou hlavní funkce kontraktu veřejné a mohou být vyvolány EOA nebo jinými kontrakty. + +Existují však také _soukromé funkce_ v rámci kontraktu, které jsou pro ostatní nepřístupné, ale které jsou klíčové pro celkovou funkčnost dApp. Příklady zahrnují funkci `mintERC721Token()`, která periodicky razí nové NFT pro uživatele, funkci pro udělování výplat na predikčním trhu nebo funkci pro odemknutí stakovaných tokenů v DEX. + +Pro zajištění hladké funkčnosti aplikace musí vývojáři tyto funkce spouštět v intervalech. To však může vést ke ztrátě času vývojářů na rutinních úkolech, což je důvod, proč je automatizace spouštění smart kontraktů atraktivní. + +Některé decentralizované sítě oraclů nabízejí automatizační služby, které umožňují offchainovým uzlům oraclu spouštět funkce smart kontraktu podle parametrů definovaných uživatelem. Typicky to vyžaduje „registraci“ cílového kontraktu u orákulové služby, poskytnutí prostředků na zaplacení provozovatele orákula a specifikaci podmínek nebo časů pro spuštění kontraktu. + +[Keeper Network](https://chain.link/keepers) od Chainlinku poskytuje smart kontraktům možnosti, jak zadat externě pravidelné úkoly údržby s minimalizovanou důvěrou a decentralizovaným způsobem. Přečtěte si oficiální [dokumentaci Keeper's](https://docs.chain.link/docs/chainlink-keepers/introduction/) pro informace o tom, jak učinit váš kontrakt kompatibilní s Keeper a jak používat službu Upkeep. + +## Jak používat blockchain oracles {#use-blockchain-oracles} + +Existuje několik orákulových aplikací, které můžete integrovat do své dappky na Ethereu: + +**[Chainlink](https://chain.link/)** – _decentralizované sítě oraclů Chainlink poskytují vstupy, výstupy a výpočty odolné proti neoprávněné manipulaci pro podporu pokročilých smart kontraktů na jakémkoli blockchainu._ + +**[RedStone Oracles](https://redstone.finance/)** – _RedStone je decentralizovaný modulární oracle, který poskytuje datové kanály optimalizované z hlediska gasu. Specializuje se na poskytování cenových kanálů pro nově vznikající aktiva, jako jsou liquid staking tokeny (LST), liquid restaking tokeny (LRT) a deriváty stakování Bitcoinu._ + +**[Chronicle](https://chroniclelabs.org/)** – _Chronicle překonává současná omezení přenosu dat onchain vývojem skutečně škálovatelných, nákladově efektivních, decentralizovaných a ověřitelných oraclů._ + +**[Witnet](https://witnet.io/)** – _Witnet je decentralizovaný oracle bez oprávnění a odolný proti cenzuře, který pomáhá smart kontraktům reagovat na události reálného světa se silnými krypto-ekonomickými zárukami._ + +**[UMA Oracle](https://uma.xyz)** – _Optimistický oracle od UMA umožňuje smart kontraktům rychle přijímat jakýkoli druh dat pro různé aplikace, včetně pojištění, finančních derivátů a predikčních trhů._ + +**[Tellor](https://tellor.io/)** – _Tellor je transparentní protokol oraclu bez oprávnění, díky kterému váš smart kontrakt snadno získá jakákoli data, kdykoli je potřebuje._ + +**[Band Protocol](https://bandprotocol.com/)** – _Band Protocol je cross-chainová platforma datových oraclů, která agreguje a propojuje data z reálného světa a API se smart kontrakty._ + +**[Pyth Network](https://pyth.network/)** – _Síť Pyth je finanční síť oraclů první strany navržená tak, aby publikovala nepřetržitá data z reálného světa onchain v prostředí odolném proti neoprávněné manipulaci, decentralizovaném a soběstačném._ + +**[API3 DAO](https://www.api3.org/)** – _API3 DAO dodává řešení oraclů první strany, která poskytují větší transparentnost zdroje, bezpečnost a škálovatelnost v decentralizovaném řešení pro smart kontrakty_ + +**[Supra](https://supra.com/)** – vertikálně integrovaná sada cross-chainových řešení, která propojují všechny blockchainy, veřejné (L1 a L2) i soukromé (podnikové), a poskytují decentralizované cenové kanály oraclů, které lze použít pro onchainové i offchainové případy použití. + +**[Gas Network](https://gas.network/)** – distribuovaná platforma oraclů poskytující data o ceně gasu v reálném čase napříč blockchainy. Tím, že přináší onchain data od předních poskytovatelů dat o cenách gasu, pomáhá Gas Network podporovat interoperabilitu. Gas Network podporuje data pro více než 35 řetězců, včetně mainnetu Ethereum a mnoha předních L2. + +## Další literatura {#further-reading} + +**Články** + +- [Co je to blockchain oracle?](https://chain.link/education/blockchain-oracles) – _Chainlink_ +- [Co je to blockchain oracle?](https://medium.com/better-programming/what-is-a-blockchain-oracle-f5ccab8dbd72) – _Patrick Collins_ +- [Decentralizované oracles: komplexní přehled](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) – _Julien Thevenard_ +- [Implementace blockchain oraclu na Ethereu](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ +- [Proč nemohou smart kontrakty volat API?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) – _StackExchange_ +- [Takže chcete použít cenový oracle](https://samczsun.com/so-you-want-to-use-a-price-oracle/) – _samczsun_ + +**Videa** + +- [Oracles a rozšíření užitečnosti blockchainu](https://youtu.be/BVUZpWa8vpw) – _Real Vision Finance_ + +**Návody** + +- [Jak získat aktuální cenu Etherea v Solidity](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) – _Chainlink_ +- [Využívání dat z oraclu](https://docs.chroniclelabs.org/Developers/tutorials/Remix) – _Chronicle_ + +**Ukázkové projekty** + +- [Kompletní startovací projekt Chainlink pro Ethereum v Solidity](https://github.com/hackbg/chainlink-fullstack) – _HackBG_ diff --git a/public/content/translations/cs/developers/docs/programming-languages/dart/index.md b/public/content/translations/cs/developers/docs/programming-languages/dart/index.md new file mode 100644 index 00000000000..77dbf4c1d3d --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/dart/index.md @@ -0,0 +1,33 @@ +--- +title: "Ethereum pro vývojáře v Dartu" +description: "Naučte se vyvíjet na Ethereu v jazyce Dart" +lang: cs +incomplete: true +--- + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +## Návody {#tutorials} + +- [Flutter and Blockchain – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) vás provede všemi kroky, jak začít: + 1. Napsání chytrého kontraktu v jazyce [Solidity](https://soliditylang.org/) + 2. Vytvoření uživatelského rozhraní v Dartu +- [Building a Mobile dapp with Flutter](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) je mnohem kratší, což může být lepší, + pokud již znáte základy +- Pokud se raději učíte sledováním videa, můžete se podívat na [Build Your First Blockchain Flutter App](https://www.youtube.com/watch?v=3Eeh3pJ6PeA), které trvá přibližně hodinu +- Pokud jste netrpěliví, možná dáte přednost videu [Building a Blockchain Decentralized-app with Flutter and Dart on Ethereum](https://www.youtube.com/watch?v=jaMFEOCq_1s), které trvá jen asi dvacet minut +- [Integrating MetaMask in Flutter application with Web3Modal by WalletConnect](https://www.youtube.com/watch?v=v_M2buHCpc4) – toto krátké video vás provede kroky integrace MetaMask do vašich aplikací Flutter pomocí knihovny [Web3Modal](https://pub.dev/packages/web3modal_flutter) od WalletConnect +- [Mobile Blockchain Developer Bootcamp Course With Solidity & Flutter](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) – playlist s kompletním kurzem pro mobilní blockchainové vývojáře + +## Práce s klienty Etherea {#working-with-ethereum-clients} + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dappky), které využívají výhody kryptoměn a blockchainových technologií. +Existují alespoň dvě aktuálně udržované knihovny pro Dart, které umožňují využívat +[JSON-RPC API](/developers/docs/apis/json-rpc/) pro Ethereum. + +1. [Web3dart od pwa.ir](https://pub.dev/packages/web3dart) +2. [Ethereum 5.0.0 od darticulate.com](https://pub.dev/packages/ethereum) + +Existují také další knihovny, které vám umožní manipulovat s konkrétními adresami na Ethereu +nebo získávat ceny různých kryptoměn. +[Celý seznam si můžete prohlédnout zde](https://pub.dev/dart/packages?q=ethereum). diff --git a/public/content/translations/cs/developers/docs/programming-languages/delphi/index.md b/public/content/translations/cs/developers/docs/programming-languages/delphi/index.md new file mode 100644 index 00000000000..2a137b8ee9c --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/delphi/index.md @@ -0,0 +1,56 @@ +--- +title: "Ethereum pro vývojáře v Delphi" +description: "Naučte se vyvíjet pro Ethereum v programovacím jazyce Delphi" +lang: cs +incomplete: true +--- + + + +Naučte se vyvíjet pro Ethereum v programovacím jazyce Delphi + + + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +Vytvářejte decentralizované aplikace na Ethereu a interagujte s chytrými kontrakty pomocí programovacího jazyka Delphi! + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Podnikněte první kroky k integraci Delphi s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Odkazy a reference pro začátečníky {#beginner-references-and-links} + +**Představujeme knihovnu Delphereum** + +- [Co je Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md) +- [Připojení Delphi k místnímu (in-memory) blockchainu](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Připojení Delphi k hlavní síti Ethereum](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [Připojení Delphi k chytrým kontraktům](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) + +**Chcete přeskočit nastavení a přejít přímo na ukázky?** + +- [Chytrý kontrakt a Delphi za 3 minuty – část 1](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [Chytrý kontrakt a Delphi za 3 minuty – část 2](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) + +## Články pro pokročilé {#intermediate-articles} + +- [Generování podpisu zprávy podepsané Ethereem v Delphi](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [Převádění etheru pomocí Delphi](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [Převádění tokenů ERC-20 pomocí Delphi](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Delphi a Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [QuikNode, Ethereum a Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) +- [Delphi a Ethereum Dark Forest](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Směna jednoho tokenu za jiný v Delphi](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/). diff --git a/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md b/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md new file mode 100644 index 00000000000..def42abb1e7 --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/dot-net/index.md @@ -0,0 +1,86 @@ +--- +title: "Ethereum pro vývojáře v .NET" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na .NET" +lang: cs +incomplete: true +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na .NET + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +Sestavte decentralizované aplikace na Ethereu a komunikujte s chytrými kontrakty pomocí nástrojů a jazyků od Microsoftu - Podpora C#, #Visual Basic .NET, F# na nástrojích jako VSCode a Visual Studio, s použitím .NET Framework/.NET Core/.NET standard. Nasaďte Ethereum blockchain na Azure pomocí Microsoft Azure Blockchainu během několika minut. Přiveďte lásku .NET na platformu Ethereum! + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Udělejte své první kroky k integraci .NET s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Odkazy a reference pro začátečníky {#beginner-references-and-links} + +**Představení knihovny Nethereum podpory Solidity ve VS Code** + +- [Nethereum, Začínáme](https://docs.nethereum.com/en/latest/getting-started/) +- [Instalace VS Code Solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [Pracovní postup .NET vývojáře pro vytváření a volání chytrých kontraktů na Ethereu](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Integrace chytrých kontraktů s Nethereum](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [Propojení .NET a chytrých kontraktů na blockchainu Etherea s Nethereum](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), také v [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) +- [Nethereum – open-source .NET integrační knihovna pro blockchain](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Zápis transakcí Etherea do SQL databáze pomocí Nethereum](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [Podívejte se, jak snadno nasadit chytré kontrakty na Ethereu pomocí C# a Visual Studia](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**Chcete přeskočit nastavení a přejít přímo na ukázky?** + +- [Playground](http://playground.nethereum.com/) – interagujte s Ethereem a naučte se, jak používat Nethereum v prohlížeči. + - Dotaz na zůstatek na účtu [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - Dotaz na zůstatek na ERC20 chytrém kontraktu [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - Převod etherů na účet [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) + - ... A více! + +## Články pro pokročilé {#intermediate-articles} + +- [Nethereum pracovní sešit / Seznam ukázek](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [Nasaďte si vlastní vývojové testnety](https://github.com/Nethereum/Testchains) +- [Plugin VSCode Codegen pro Solidity](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity a Ethereum: Proč a jak](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [Vytvoření webového API ASP.NET Core pro Ethereum dapps](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [Použití Nethereum Web3 k implementaci systému pro sledování dodavatelského řetězce](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Zpracování bloků v Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/) s [ukázkou pro C# Playground](http://playground.nethereum.com/csharp/id/1025) +- [Streamování přes websocket v Nethereum](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Kaleido a Nethereum](https://kaleido.io/kaleido-and-nethereum/) +- [Quorum a Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Azure Key Vault a Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) +- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) +- [Referenční architektura backendu Ujo Nethereum](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) + +## .NET projekty, nástroje a další zajímavosti {#dot-net-projects-tools-and-other-fun-stuff} + +- [Nethereum Playground](http://playground.nethereum.com/) – _kompilujte, vytvářejte a spouštějte úryvky kódu Nethereum v prohlížeči_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) – _Nethereum codegen s UI v Blazor_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) – _lehký .NET Wasm SPA prohlížeč blockchainu a jednoduchá peněženka_ +- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) – _engine pro obchodní pravidla (pro platformy .NET i Ethereum), který je ze své podstaty řízen metadaty_ +- [Nethermind](https://github.com/NethermindEth/nethermind) – _klient Etherea v .NET Core pro Linux, Windows a macOS_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _pomocné funkce pro práci s kódovými bázemi souvisejícími s Ethereem_ +- [TestChains](https://github.com/Nethereum/TestChains) – _předkonfigurované .NET devchainy pro rychlou odezvu (PoA)_ + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/). + +## Přispěvatelé .NET komunity {#dot-net-community-contributors} + +My v Nethereum se většinou scházíme na [Gitteru](https://gitter.im/Nethereum/Nethereum), kde se každý může ptát a odpovídat na otázky, získat pomoc nebo prostě jen tak relaxovat. Neváhejte vytvořit PR nebo otevřít issue v [repozitáři Nethereum na GitHubu](https://github.com/Nethereum), nebo si jen projděte mnoho vedlejších a ukázkových projektů, které máme. Najdete nás také na [Discordu](https://discord.gg/jQPrR58FxX)! + +Pokud s Nethermindem začínáte a potřebujete pomoc, připojte se na náš [Discord](http://discord.gg/PaCMRFdvWT). Naši vývojáři jsou připraveni zodpovědět vaše otázky. Neváhejte otevřít PR nebo nahlásit jakékoliv problémy v [repozitáři Nethermind na GitHubu](https://github.com/NethermindEth/nethermind). + +## Další souhrnné seznamy {#other-aggregated-lists} + +[Oficiální stránky Nethereum](https://nethereum.com/) +[Oficiální stránky Nethermind](https://nethermind.io/) diff --git a/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md b/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md new file mode 100644 index 00000000000..c804842aa3a --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/elixir/index.md @@ -0,0 +1,55 @@ +--- +title: "Ethereum pro Elixir vývojáře" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Elixiru." +lang: cs +incomplete: false +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Elixiru. + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace nevyžadují, abyste jim důvěřovali, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Udělejte první kroky k integraci Elixiru s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Články pro začátečníky {#beginner-articles} + +- [Konečně pochopení účtů na Ethereu](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers – prvotřídní Web3 knihovna pro Ethereum v Elixiru](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## Články pro pokročilé {#intermediate-articles} + +- [Jak podepsat surové transakce ethereových kontraktů pomocí Elixiru](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [Chytré kontrakty na Ethereu a Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Elixir projekty a nástroje {#elixir-projects-and-tools} + +### Aktivní {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) – _implementace BIP32 a BIP44 v Elixiru (hierarchie více účtů pro deterministické peněženky)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) – _Elixir JSON-RPC klient pro blockchain Etherea_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) – _komplexní Web3 knihovna pro interakci s chytrými kontrakty na Ethereu pomocí Elixiru_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) – _KMS knihovna podepisovače pro Ethers (podepisování transakcí pomocí AWS KMS)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) – _implementace parseru/dekodéru/kodéru Ethereum ABI v Elixiru_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) – _knihovna Elixiru pro výpočet hašů Keccak SHA3-256 pomocí NIF postaveného na Rust crate tiny-keccak_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) – _implementace kódování RLP (Recursive Length Prefix) Etherea v Elixiru_ + +### Archivované / Již neudržované {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) – _nástroje pro Ethereum v Elixiru_ +- [exw3](https://github.com/hswick/exw3) – _vysokoúrovňový Ethereum RPC klient pro Elixir_ +- [mana](https://github.com/mana-ethereum/mana) – _implementace plného uzlu Etherea napsaná v Elixiru_ + +Hledáte další informační zdroje? Podívejte se na naši [domovskou stránku pro vývojáře](/developers/). + +## Přispěvatelé z komunity Elixiru {#elixir-community-contributors} + +[Kanál #ethereum na Slacku Elixiru](https://elixir-lang.slack.com/archives/C5RPZ3RJL) hostí rychle se rozrůstající komunitu a je vyhrazeným zdrojem pro diskuze o jakýchkoliv výše uvedených projektech a souvisejících tématech. diff --git a/public/content/translations/cs/developers/docs/programming-languages/golang/index.md b/public/content/translations/cs/developers/docs/programming-languages/golang/index.md new file mode 100644 index 00000000000..1d1d8c40b9d --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/golang/index.md @@ -0,0 +1,84 @@ +--- +title: "Ethereum pro vývojáře v Go" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů v jazyce Go" +lang: cs +incomplete: true +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů v jazyce Go + +Použijte Ethereum k vytváření decentralizovaných aplikací (neboli "dapps"). Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Jsou decentralizované, což znamená, že běží na síti peer-to-peer a neexistuje žádný jediný bod selhání. Nekontroluje je žádná jediná entita ani osoba a je téměř nemožné je cenzurovat. Mohou ovládat digitální aktiva, aby mohly vytvářet nové druhy aplikací. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Udělejte své první kroky k integraci jazyka Go s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Tutoriál ke kontraktům](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) + +## Články a knihy pro začátečníky {#beginner-articles-and-books} + +- [Začínáme s Geth](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) +- [Použití Golang k připojení k Ethereu](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Nasazení chytrých kontraktů na Ethereu pomocí Golang](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Podrobný průvodce testováním a nasazením chytrých kontraktů na Ethereu v Go](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [eBook: Vývoj pro Ethereum s Go](https://goethereumbook.org/) – _Vyvíjejte aplikace pro Ethereum pomocí Go_ + +## Články a dokumentace pro středně pokročilé {#intermediate-articles-and-docs} + +- [Dokumentace Go Ethereum](https://geth.ethereum.org/docs/) – _Dokumentace pro oficiální podporu jazyka Go v projektu Ethereum_ +- [Programátorská příručka Erigon](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) – _Ilustrovaný průvodce včetně stavového stromu, multi-proofs a zpracování transakcí_ +- [Erigon a bezestavové Ethereum](https://youtu.be/3-Mn7OckSus?t=394) – _Konference komunity Etherea 2020 (EthCC 3)_ +- [Erigon: optimalizace klientů Etherea](https://www.youtube.com/watch?v=CSpc1vZQW2Q) – _Devcon 4 2018_ +- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [Vytvoření dapp v Go pomocí Geth](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [Práce se soukromou sítí Ethereum pomocí Golang a Geth](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Unit testování kontraktů Solidity na Ethereu s Go](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Rychlá reference pro používání Geth jako knihovny](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Simulovaný backend GETH](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [Aplikace typu Blockchain jako služba využívající Ethereum a Quorum](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [Distribuované úložiště IPFS a Swarm v blockchainových aplikacích Etherea](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [Mobilní klienti: knihovny a Inproc uzly Ethereum](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [Nativní dapps: Go bindings pro kontrakty Etherea](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) + +## Go projekty a nástroje {#go-projects-and-tools} + +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) – _Oficiální implementace protokolu Ethereum v Go_ +- [Analýza kódu Go Ethereum](https://github.com/ZtesoftCS/go-ethereum-code-analysis) – _Přehled a analýza zdrojového kódu Go Ethereum_ +- [Erigon](https://github.com/ledgerwatch/erigon) – _Rychlejší derivát Go Ethereum se zaměřením na archivní uzly_ +- [Golem](https://github.com/golemfactory/golem) – _Golem vytváří globální trh s výpočetním výkonem_ +- [Quorum](https://github.com/jpmorganchase/quorum) – _Implementace Etherea s kontrolou přístupu, která podporuje ochranu soukromí_ +- [Prysm](https://github.com/prysmaticlabs/prysm) – _Implementace Etherea 'Serenity' 2.0 v Go_ +- [Eth Tweet](https://github.com/yep/eth-tweet) – _Decentralizovaný Twitter: Mikroblogovací služba běžící na blockchainu Etherea_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _Implementace v Golang a rozšíření specifikace Minimum Viable Plasma_ +- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) – _Open-source těžební pool pro Ethereum_ +- [Ethereum HD peněženka](https://github.com/miguelmota/go-ethereum-hdwallet) – _Odvození Ethereum HD peněženky v Go_ +- [Multi Geth](https://github.com/multi-geth/multi-geth) – _Podpora pro mnoho druhů sítí Ethereum_ +- [Geth lehký klient](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) – _Implementace Geth lehkého subprotokolu Etherea_ +- [Ethereum Golang SDK](https://github.com/everFinance/goether) – _Jednoduchá implementace peněženky Ethereum a utility v Golang_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) – _Efektivní přístup k blockchainovým datům prostřednictvím Go SDK pro více než 200 blockchainů_ + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/) + +## Přispěvatelé komunity Go {#go-community-contributors} + +- [Geth Discord](https://discordapp.com/invite/nthXNEv) +- [Geth Gitter](https://gitter.im/ethereum/go-ethereum) +- [Gophers Slack](https://invite.slack.golangbridge.org/) – [kanál #ethereum](https://gophers.slack.com/messages/C9HP1S9V2) +- [StackExchange – Ethereum](https://ethereum.stackexchange.com/) +- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth) +- [Ethereum Gitter](https://gitter.im/ethereum/home) +- [Geth lehký klient Gitter](https://gitter.im/ethereum/light-client) + +## Další souhrnné seznamy {#other-aggregated-lists} + +- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: Definitivní seznam vývojářských nástrojů pro Ethereum](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [Zdroj na GitHubu](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git a/public/content/translations/cs/developers/docs/programming-languages/index.md b/public/content/translations/cs/developers/docs/programming-languages/index.md new file mode 100644 index 00000000000..6d0e0e5cd9d --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/index.md @@ -0,0 +1,33 @@ +--- +title: "Programovací jazyky" +description: "Objevte vývojářské zdroje informací pro Ethereum v různých programovacích jazycích, včetně JavaScript, Python, Go, Rust a dalších." +lang: cs +--- + +Častou mylnou představou je, že vývojáři musí psát [chytré kontrakty](/developers/docs/smart-contracts/), aby mohli stavět na Ethereu. To není pravda. +Jednou z krás sítě Ethereum a její komunity je, že se můžete [zapojit](/community/) v téměř jakémkoli programovacím jazyce. + +Ethereum a jeho komunita podporují open source. Komunitní projekty - implementace klientů, API, vývojové frameworky, testovací nástroje - existují v široké škále jazyků. + +## Vyberte si jazyk {#data} + +Vyberte svůj oblíbený programovací jazyk a podívejte se na projekty, zdroje a virtuální komunity: + +- [Ethereum pro vývojáře v Dartu](/developers/docs/programming-languages/dart/) +- [Ethereum pro vývojáře v Delphi](/developers/docs/programming-languages/delphi/) +- [Ethereum pro vývojáře v .NET](/developers/docs/programming-languages/dot-net/) +- [Ethereum pro vývojáře v Elixiru](/developers/docs/programming-languages/elixir/) +- [Ethereum pro vývojáře v Go](/developers/docs/programming-languages/golang/) +- [Ethereum pro vývojáře v Javě](/developers/docs/programming-languages/java/) +- [Ethereum pro vývojáře v JavaScriptu](/developers/docs/programming-languages/javascript/) +- [Ethereum pro vývojáře v Pythonu](/developers/docs/programming-languages/python/) +- [Ethereum pro vývojáře v Ruby](/developers/docs/programming-languages/ruby/) +- [Ethereum pro vývojáře v Rustu](/developers/docs/programming-languages/rust/) + +### Co když můj jazyk není podporován {#other-lang} + +Chcete-li přidat odkazy na zdroje informací nebo na virtuální komunitu pro další programovací jazyk, můžete o novou stránku požádat [otevřením „issue“](https://github.com/ethereum/ethereum-org-website/issues/new/choose). + +Pokud chcete psát kód pro komunikaci s blockchainem pomocí aktuálně nepodporovaného jazyka, +můžete se k síti Ethereum připojit pomocí [rozhraní JSON-RPC](/developers/docs/apis/json-rpc/). Jakýkoliv programovací +jazyk, který umí pracovat s TCP/IP, může toto rozhraní použít. diff --git a/public/content/translations/cs/developers/docs/programming-languages/java/index.md b/public/content/translations/cs/developers/docs/programming-languages/java/index.md new file mode 100644 index 00000000000..b5327a8f724 --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/java/index.md @@ -0,0 +1,64 @@ +--- +title: "Ethereum pro vývojáře v Javě" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Javě" +lang: cs +incomplete: true +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Javě + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Udělejte své první kroky k integraci Javy s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers.](/developers/) + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Práce s klienty Etherea {#working-with-ethereum-clients} + +Naučte se používat [Web3J](https://github.com/web3j/web3j) a Hyperledger Besu, dva přední Java Ethereum klienty + +- [Připojení ke klientovi pro Ethereum pomocí Javy, Eclipse a Web3J](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [Správa účtu Ethereum pomocí Javy a Web3j](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [Generování Java wrapperu z vašeho chytrého kontraktu](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [Interakce s chytrým kontraktem Ethereum](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [Naslouchání událostem chytrého kontraktu Ethereum](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [Použití Besu (Pantheon), klienta pro Ethereum v Javě s Linuxem](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Spuštění uzlu Hyperledger Besu (Pantheon) v integračních testech v Javě](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Tahák na Web3j](https://kauri.io/web3j-cheat-sheet-\(java-ethereum\)/5dfa1ea941ac3d0001ce1d90/c) + +Naučte se používat [ethers-kt](https://github.com/Kr1ptal/ethers-kt), asynchronní, vysoce výkonnou knihovnu v Kotlinu pro interakci s blockchainy založenými na EVM. Cíleno na platformy JVM a Android. + +- [Převod tokenů ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [Směna na UniswapV2 s nasloucháním událostem](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +- [Sledování zůstatku ETH / ERC20](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) + +## Články pro pokročilé {#intermediate-articles} + +- [Správa úložiště v aplikaci v Javě pomocí IPFS](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [Správa tokenů ERC20 v Javě pomocí Web3j](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Správci transakcí Web3j](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Použití Eventeum k vytvoření datové mezipaměti chytrého kontraktu v Javě](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) + +## Projekty a nástroje v Javě {#java-projects-and-tools} + +- [Web3J (knihovna pro interakci s klienty pro Ethereum)](https://github.com/web3j/web3j) +- [ethers-kt (Asynchronní, vysoce výkonná knihovna pro Kotlin/Javu/Android pro blockchainy založené na EVM.)](https://github.com/Kr1ptal/ethers-kt) +- [Eventeum (naslouchač událostí)](https://github.com/ConsenSys/eventeum) +- [Mahuta (vývojářské nástroje pro IPFS)](https://github.com/ConsenSys/mahuta) + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers.](/developers/) + +## Komunitní přispěvatelé pro Javu {#java-community-contributors} + +- [IO Builders](https://io.builders) +- [Kauri](https://kauri.io) diff --git a/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md b/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md new file mode 100644 index 00000000000..2e9c50ec513 --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/javascript/index.md @@ -0,0 +1,72 @@ +--- +title: "Ethereum pro vývojáře v JavaScriptu" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na JavaScriptu." +lang: cs +--- + +JavaScript je jedním z nejpopulárnějších jazyků v ekosystému Ethereum. Ve skutečnosti existuje [tým](https://github.com/ethereumjs) věnovaný tomu, aby co nejvíce z Etherea přenesl do JavaScriptu. + +Existují příležitosti k psaní v JavaScriptu (nebo něčem blízkém) na [všech úrovních zásobníku](/developers/docs/ethereum-stack/). + +## Interakce s Ethereem {#interact-with-ethereum} + +### JavaScriptové API knihovny {#javascript-api-libraries} + +Pokud byste chtěli psát v JavaScriptu pro dotazování blockchainu, odesílání transakcí a další, nejpohodlnější způsob, jak to udělat, je použít [knihovnu JavaScript API](/developers/docs/apis/javascript/). Tato API umožňují vývojářům snadno komunikovat s [uzly v síti Ethereum](/developers/docs/nodes-and-clients/). + +Tyto knihovny můžete použít k interakci s chytrými kontrakty na Ethereu, takže je možné vytvořit dapp, kde pro interakci s již existujícími kontrakty použijete pouze JavaScript. + +**Podívejte se** + +- [Web3.js](https://web3js.readthedocs.io) +- [Ethers.js](https://ethers.org) – _zahrnuje implementaci peněženky Ethereum a utility v JavaScriptu a TypeScriptu._ +- [viem](https://viem.sh) – _rozhraní TypeScriptu pro Ethereum, které poskytuje nízkoúrovňové bezstavové primitivy pro interakci s Ethereem._ +- [Drift](https://ryangoree.github.io/drift/) – _meta-knihovna TypeScriptu s vestavěným ukládáním do mezipaměti, háčky a testovacími maketami pro snadný vývoj na Ethereu napříč knihovnami web3._ + +### Chytré kontrakty {#smart-contracts} + +Pokud jste JavaScript vývojář a chcete psát svůj vlastní chytrý kontrakt, možná se budete chtít seznámit se [Solidity](https://solidity.readthedocs.io). Jedná se o nejpopulárnější jazyk pro chytré kontrakty a je syntakticky podobný JavaScriptu, což může usnadnit jeho učení. + +Více o [chytrých kontraktech](/developers/docs/smart-contracts/). + +## Pochopení protokolu {#understand-the-protocol} + +### Virtuální stroj Etherea {#the-ethereum-virtual-machine} + +Existuje JavaScriptová implementace [virtuálního stroje Etherea](/developers/docs/evm/). Podporuje nejnovější pravidla větví. Pravidla větví odkazují na změny provedené v EVM v důsledku plánovaných upgradů. + +Je rozdělen do různých JavaScriptových balíčků, které si můžete prohlédnout, abyste lépe porozuměli: + +- Účty +- Bloky +- Samotný blockchain +- Transakce +- A další... + +To vám pomůže pochopit věci jako "jaká je datová struktura účtu?". + +Pokud dáváte přednost čtení kódu, tento JavaScript může být skvělou alternativou ke čtení naší dokumentace. + +**Prozkoumejte EVM** +[`@ethereumjs/evm`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/evm) + +### Uzly a klienti {#nodes-and-clients} + +Klient Ethereumjs je v aktivním vývoji, který vám umožní ponořit se do toho, jak fungují klienti Etherea, v jazyce, kterému rozumíte: v JavaScriptu! + +**Prozkoumejte klienta** +[`@ethereumjs/client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) + +## Další projekty {#other-projects} + +V zemi Etherea a JavaScriptu se toho děje spousta, včetně: + +- knihovny s utilitami pro peněženky. +- nástroje pro generování, import a export klíčů Ethereum. +- implementace `merkle-patricia-tree` – datové struktury popsané ve žluté knize Etherea. + +Ponořte se do toho, co vás nejvíce zajímá, v [repozitáři EthereumJS](https://github.com/ethereumjs) + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ diff --git a/public/content/translations/cs/developers/docs/programming-languages/python/index.md b/public/content/translations/cs/developers/docs/programming-languages/python/index.md new file mode 100644 index 00000000000..f6031c73d6f --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/python/index.md @@ -0,0 +1,99 @@ +--- +title: "Ethereum pro vývojáře v Pythonu" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Pythonu" +lang: cs +incomplete: true +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Pythonu + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Udělejte své první kroky k integraci Pythonu s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Zpráva o stavu Pythonu v blockchainu v roce 2023](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) + +## Články pro začátečníky {#beginner-articles} + +- [Přehled web3.py](https://web3py.readthedocs.io/en/latest/overview.html) +- [Prohlídka ekosystému Ethereum a Pythonu](https://snakecharmers.ethereum.org/python-ecosystem/) +- [Průvodce Ethereum pro (Python) vývojáře](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [Prize-Worthy: Průvodce hackathonem pro Ethereum a Python](https://snakecharmers.ethereum.org/prize-worthy/) +- [Úvod do chytrých kontraktů s Vyper](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Jak vyvíjet kontrakt pro Ethereum pomocí Python Flask?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Úvod do Web3.py · Ethereum pro vývojáře v Pythonu](https://www.dappuniversity.com/articles/web3-py-intro) +- [Jak volat funkci chytrého kontraktu pomocí Python a web3.py](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) + +## Články pro pokročilé {#intermediate-articles} + +- [Přátelé web3.py: Úvod do Ape](https://snakecharmers.ethereum.org/intro-to-ape/) +- [Vývoj dapp pro programátory v Pythonu](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [Vytvoření rozhraní Ethereum v Pythonu: Část 1](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Chytré kontrakty na Ethereum v Pythonu: komplexní průvodce (tak trochu)](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Vzory web3.py: Odběry událostí v reálném čase](https://snakecharmers.ethereum.org/subscriptions/) +- [Vzory web3.py: WebSocketProvider](https://snakecharmers.ethereum.org/websocketprovider/) +- [Kompilace, nasazení a volání chytrého kontraktu na Ethereum pomocí Pythonu](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Analyzujte chytré kontrakty Solidity pomocí Slither](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [Blockchain Fintech Tutoriál: Půjčování a vypůjčování s Pythonem](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## Archivované články + +- [Nasaďte svůj vlastní ERC20 token s Pythonem a Brownie](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [Použití Brownie a Pythonu k nasazení chytrých kontraktů](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [Vytváření NFT na OpenSea pomocí Brownie](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## Projekty a nástroje pro Python {#python-projects-and-tools} + +### Aktivní: {#active} + +- [Web3.py](https://github.com/ethereum/web3.py) - _knihovna Pythonu pro interakci s Ethereum_ +- [Vyper](https://github.com/ethereum/vyper/) - _Pythonický jazyk pro chytré kontrakty pro EVM_ +- [Ape](https://github.com/ApeWorX/ape) - _nástroj pro vývoj chytrých kontraktů pro Pythonisty, datové vědce a bezpečnostní profesionály_ +- [py-evm](https://github.com/ethereum/py-evm) - _implementace Ethereum Virtual Machine_ +- [eth-tester](https://github.com/ethereum/eth-tester) - _nástroje pro testování aplikací založených na Ethereum_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _pomocné funkce pro práci s kódovými bázemi souvisejícími s Ethereem_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) - _Python wrapper pro kompilátor solc pro Solidity s podporou 0.5.x_ +- [pymaker](https://github.com/makerdao/pymaker) - _Python API pro kontrakty Maker_ +- [siwe](https://github.com/signinwithethereum/siwe-py) - _Sign in with Ethereum (siwe) pro Python_ +- [Web3 DeFi for Ethereum integrations](https://github.com/tradingstrategy-ai/web3-ethereum-defi) - _Balíček Pythonu s připravenými integracemi pro ERC-20, Uniswap a další populární projekty_ +- [Wake](https://getwake.io) - _All-in-one Python framework pro testování kontraktů, fuzzing, nasazení, skenování zranitelností a navigaci v kódu (jazykový server – [Tools for Solidity](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### Archivováno / Již se neudržuje: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) - _Python klient pro Ethereum_ +- [Mamba](https://github.com/arjunaskykok/mamba) - _framework pro psaní, kompilaci a nasazení chytrých kontraktů napsaných v jazyce Vyper_ +- [Brownie](https://github.com/eth-brownie/brownie) - _Python framework pro nasazení, testování a interakci s chytrými kontrakty Etherea_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) - _implementace P2P stacku Etherea_ +- [py-wasm](https://github.com/ethereum/py-wasm) - _implementace interpreta WebAssembly v Pythonu_ + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers](/developers/). + +## Projekty využívající nástroje pro Python {#projects-using-python-tooling} + +Následující projekty založené na Ethereu používají nástroje uvedené na této stránce. Související open-source repozitáře slouží jako dobrý referenční zdroj pro příklady kódu a osvědčené postupy. + +- [Yearn Finance](https://yearn.finance/) a [repozitář Yearn Vault Contracts](https://github.com/yearn/yearn-vaults) +- [Curve](https://www.curve.finance/) a [repozitář chytrých kontraktů Curve](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) a [chytré kontrakty využívající sadu nástrojů Brownie](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/) používá [Python při správě a nasazování svých vestingových kontraktů](https://github.com/sushiswap/sushi-vesting-protocols) +- [Alpha Finance](https://alphafinance.io/), známá díky Alpha Homora, používá [Brownie k testování a nasazení chytrých kontraktů](https://github.com/AlphaFinanceLab/alpha-staking-contract) + +## Diskuse komunity Pythonu {#python-community-contributors} + +- [Discord komunity Ethereum a Pythonu](https://discord.gg/9zk7snTfWe) pro diskuzi o Web3.py a dalších frameworcích pro Python +- [Discord pro Vyper](https://discord.gg/SdvKC79cJk) pro diskuzi o programování chytrých kontraktů v jazyce Vyper + +## Další souhrnné seznamy {#other-aggregated-lists} + +Wiki pro Vyper má [neuvěřitelný seznam zdrojů pro Vyper](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) \ No newline at end of file diff --git a/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md b/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md new file mode 100644 index 00000000000..57c22138e57 --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/ruby/index.md @@ -0,0 +1,60 @@ +--- +title: "Ethereum pro vývojáře v Ruby" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Ruby." +lang: cs +incomplete: false +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Ruby. + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace nevyžadují, abyste jim důvěřovali, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Podnikněte první kroky k integraci Ruby s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Články pro začátečníky {#beginner-articles} + +- [Konečně pochopení účtů na Ethereu](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Konečně ověřování uživatelů Rails pomocí MetaMask](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [Jak se připojit k síti Ethereum pomocí Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [Jak vygenerovat novou adresu Ethereum v Ruby](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) + +## Články pro pokročilé {#intermediate-articles} + +- [Blockchainová aplikace s Ruby](https://www.nopio.com/blog/blockchain-app-ruby/) +- [Použití Ruby, připojeného k Ethereu, ke spuštění chytrého kontraktu](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) + +## Projekty a nástroje Ruby {#ruby-projects-and-tools} + +### Aktivní {#active} + +- [eth.rb](https://github.com/q9f/eth.rb) – _knihovna Ruby a klient RPC pro správu účtů, zpráv a transakcí Etherea_ +- [keccak.rb](https://github.com/q9f/keccak.rb) – _haš Keccak (SHA3) používaný Ethereem_ +- [siwe-ruby](https://github.com/signinwithethereum/siwe-ruby) – _implementace Sign-In with Ethereum v Ruby_ +- [siwe-rails](https://github.com/signinwithethereum/siwe-rails) – _gem pro Rails, který přidává lokální cesty pro přihlášení pomocí SIWE_ +- [siwe-rails-examples](https://github.com/signinwithethereum/siwe-rails-examples) – _příklad SIWE s použitím Ruby on Rails s vlastním kontrolerem_ +- [omniauth-siwe](https://github.com/signinwithethereum/omniauth-siwe) – _strategie OmniAuth pro Sign In With Ethereum (SIWE)_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) – _strategie OmniAuth pro ověřování prostřednictvím vlastnictví NFT_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) – _šablona Ethereum on Rails, která umožňuje připojit MetaMask k Ruby on Rails_ + +### Archivované / Již neudržované {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) – _volání RPC metod uzlu Ethereum pomocí Ruby_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) – _knihovna Ruby pro generování ETH adres z hierarchicky deterministické peněženky podle standardu BIP32_ +- [etherlite](https://github.com/budacom/etherlite) – _integrace Etherea pro Ruby on Rails_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) – _klient Etherea v Ruby používající rozhraní JSON-RPC pro odesílání transakcí, vytváření kontraktů a interakci s nimi a také užitečná sada nástrojů pro práci s uzlem Ethereum_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) – _implementuje strategii poskytovatele Etherea pro OmniAuth_ + +Hledáte další informační zdroje? Podívejte se na naši [domovskou stránku pro vývojáře](/developers/). + +## Přispěvatelé komunity Ruby {#ruby-community-contributors} + +[Telegramová skupina Ethereum Ruby](https://t.me/ruby_eth) hostí rychle rostoucí komunitu a je specializovaným zdrojem pro diskuse o všech výše uvedených projektech a souvisejících tématech. diff --git a/public/content/translations/cs/developers/docs/programming-languages/rust/index.md b/public/content/translations/cs/developers/docs/programming-languages/rust/index.md new file mode 100644 index 00000000000..8167a2d99c7 --- /dev/null +++ b/public/content/translations/cs/developers/docs/programming-languages/rust/index.md @@ -0,0 +1,65 @@ +--- +title: "Ethereum pro vývojáře v Rustu" +description: "Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Rustu" +lang: cs +incomplete: true +--- + +Naučte se vyvíjet pro Ethereum pomocí projektů a nástrojů založených na Rustu + +Na platformě Ethereum můžete vytvářet decentralizované aplikace (neboli dapps), které využívají výhody kryptoměn a blockchainové technologie. Tyto aplikace mohou být důvěryhodné, což znamená, že jakmile je jednou nasadíte na Ethereum, budou vždy spouštěny přesně tak, jak jsou naprogramovány. Tyto aplikace mohou kontrolovat digitální aktiva, a tím vytvářet nové druhy finančních aplikací. Mohou být decentralizované, což znamená, že je nemůže ovládat jediná entita nebo osoba a že jsou téměř necenzurovatelné. + +## Začínáme s chytrými kontrakty a jazykem Solidity {#getting-started-with-smart-contracts-and-solidity} + +**Udělejte své první kroky k integraci Rustu s Ethereem** + +Potřebujete nejdříve úplně základní informace? Podívejte se na [ethereum.org/learn](/learn/) nebo [ethereum.org/developers](/developers/). + +- [Vysvětlení blockchainu](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Porozumění chytrým kontraktům](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Napište svůj první chytrý kontrakt](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Naučte se kompilovat a nasazovat Solidity](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Články pro začátečníky {#beginner-articles} + +- [Klient Ethereum v Rustu](https://openethereum.github.io/) \* **Upozornění: OpenEthereum [je zastaralý](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd) a již není udržován.** Používejte jej opatrně a nejlépe přejděte na jinou implementaci klienta. +- [Posílání transakcí do Etherea pomocí Rustu](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Postupný návod, jak psát kontrakty v Rustu a Wasmu pro Kovan](https://github.com/paritytech/pwasm-tutorial) + +## Články pro pokročilé {#intermediate-articles} + +## Pokročilé vzory použití {#advanced-use-patterns} + +- [Knihovna pwasm_ethereum externs pro interakci se sítěmi podobnými Ethereu](https://github.com/openethereum/pwasm-ethereum) + +- [Sestavení decentralizovaného chatu pomocí JavaScriptu a Rustu](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) + +- [Sestavení decentralizované todo aplikace pomocí Vue.js a Rustu](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Sestavení blockchainu v Rustu](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Projekty a nástroje v Rustu {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) - _Sbírka externů pro interakci se sítěmi podobnými Ethereu_ +- [Lighthouse](https://github.com/sigp/lighthouse) - _Rychlý klient konsensuální vrstvy Etherea_ +- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) - _Navrhovaný redesign exekuční vrstvy chytrých kontraktů Etherea pomocí deterministické podmnožiny WebAssembly_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _Reference OASIS API_ +- [Solaris](https://github.com/paritytech/sol-rs) - _Nástroj pro jednotkové testování chytrých kontraktů v Solidity využívající nativní EVM klienta Parity._ +- [SputnikVM](https://github.com/rust-blockchain/evm) - _Implementace Ethereum Virtual Machine (EVM) v Rustu_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) - _Chytrý kontrakt Wavelet v Rustu_ +- [Foundry](https://github.com/foundry-rs/foundry) - _Sada nástrojů pro vývoj aplikací pro Ethereum_ +- [Alloy](https://alloy.rs) - _Vysoce výkonné, dobře otestované a zdokumentované knihovny pro interakci s Ethereem a dalšími řetězci založenými na EVM._ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) - _Implementace knihovny a peněženky pro Ethereum_ +- [SewUp](https://github.com/second-state/SewUp) - _Knihovna, která vám pomůže vytvořit kontrakt pro Ethereum WebAssembly v Rustu, stejně jako při vývoji běžného backendu_ +- [Substreams](https://github.com/streamingfast/substreams) - _Technologie pro paralelizované indexování dat z blockchainu_ +- [Reth](https://github.com/paradigmxyz/reth) Reth (zkratka pro Rust Ethereum) je nová implementace plného uzlu Etherea +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) - _Spravovaná sbírka projektů v ekosystému Etherea napsaných v Rustu_ + +Hledáte další informační zdroje? Podívejte se na [ethereum.org/developers.](/developers/) + +## Přispěvatelé komunity Rust {#rust-community-contributors} + +- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) +- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) +- [Parity Gitter](https://gitter.im/paritytech/parity) +- [Enigma](https://discord.gg/SJK32GY) diff --git a/public/content/translations/cs/developers/docs/scaling/index.md b/public/content/translations/cs/developers/docs/scaling/index.md index 47b67364562..1aef8c745b4 100644 --- a/public/content/translations/cs/developers/docs/scaling/index.md +++ b/public/content/translations/cs/developers/docs/scaling/index.md @@ -1,6 +1,6 @@ --- -title: Škálování -description: Úvod do různých škálovacích možností, které v současné době vyvíjí ethereovská komunita. +title: "Škálování" +description: "Úvod do různých škálovacích možností, které v současné době vyvíjí ethereovská komunita." lang: cs sidebarDepth: 3 --- @@ -9,27 +9,27 @@ sidebarDepth: 3 S růstem počtu lidí používajících Ethereum narazil tento blockchain na určité kapacitní limity. To vedlo ke zvýšení nákladů na používání sítě a vytvořilo potřebu „škálovacích řešení.“ Existuje několik řešení, která se zkoumají, testují a implementují, přičemž každé přistupuje k dosažení podobných cílů různými způsoby. -Hlavním cílem škálování je zvýšit rychlost transakcí (rychlejší finalita) a propustnost transakcí (vyšší počet transakcí za sekundu), aniž by byla obětována decentralizace nebo bezpečnost (více o [vizi Etherea](/roadmap/vision/)). Na blockchainu vrstvy 1 Ethera vede vysoká poptávka k pomalejším transakcím a neudržitelným [palivovým cenám](/developers/docs/gas/). Zvýšení kapacity sítě z hlediska rychlosti a propustnosti je zásadní pro smysluplné a masové přijetí Etherea. +Hlavním cílem škálovatelnosti je zvýšit rychlost transakcí (rychlejší finalita) a propustnost transakcí (vyšší počet transakcí za sekundu), aniž by byla obětována decentralizace nebo bezpečnost. Na blockchainu Ethereum vrstvy 1 vede vysoká poptávka k pomalejším transakcím a neudržitelným [cenám za gas](/developers/docs/gas/). Zvýšení kapacity sítě z hlediska rychlosti a propustnosti je zásadní pro smysluplné a masové přijetí Etherea. Zatímco rychlost a propustnost jsou důležité, je nezbytné, aby škálovací řešení umožňující tyto cíle zůstala decentralizovaná a bezpečná. Udržení nízké bariéry pro vstup pro operátory síťových uzlů je klíčové k tomu, aby se zabránilo přechodu k centralizovanému a nezabezpečenému výpočetnímu výkonu. -Konceptuálně nejprve rozdělíme škálování na on-chain škálování a off-chain škálování. +Koncepčně nejprve dělíme škálování na on-chain škálování a off-chain škálování. ## Předpoklady {#prerequisites} Měli byste dobře rozumět všem základním tématům. Implementace škálovacích řešení je pokročilým tématem, protože tato technologie není zatím dostatečně otestována v praxi a stále se vyvíjí a zkoumá. -## On-chain škálování {#on-chain-scaling} +## On-chain škálování {#onchain-scaling} -On-chain škálování vyžaduje změny v protokolu Etherea ([Mainnet](/glossary/#mainnet) vrstvy 1). Dlouhou dobu se očekávalo, že Ethereum bude škálováno prostřednictvím shardingu. To mělo zahrnovat rozdělení blockchainu na oddělené části (shardy), které by byly ověřovány podskupinami validátorů. Ale hlavní technikou škálování se postupně stalo škálování pomocí rollupů na vrstvě 2. To je podporováno přidáním nové levnější formy dat připojených k blokům Etherea, která je speciálně navržena tak, aby byly rollupy pro uživatele levné. +On-chain škálování vyžaduje změny v protokolu Ethereum (vrstva 1 [Mainnet](/glossary/#mainnet)). Dlouhou dobu se očekávalo, že Ethereum bude škálováno prostřednictvím shardingu. To mělo zahrnovat rozdělení blockchainu na oddělené části (shardy), které by byly ověřovány podskupinami validátorů. Ale hlavní technikou škálování se postupně stalo škálování pomocí rollupů na vrstvě 2. To je podporováno přidáním nové levnější formy dat připojených k blokům Etherea, která je speciálně navržena tak, aby byly rollupy pro uživatele levné. ### Sharding {#sharding} -Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardery, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí plánu vývoje Etherea a měl být původně zaveden před přechodem na proof-of-stake (Sloučení). Avšak rychlý vývoj [rollupů na vrstvě 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání blobů dat z rollupů do bloků Etherea, které mohou být velmi efektivně ověřovány validátory) vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší. +Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardery, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí [plánu](/roadmap/) Etherea a původně se počítalo s jeho spuštěním před přechodem na proof-of-stake (The Merge). Rychlý vývoj [rollupů vrstvy 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání datových blobů z rollupů do bloků Etherea, které mohou validátoři velmi efektivně ověřit) však vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto škálování pomocí shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší. -## Off-chain škálování {#off-chain-scaling} +## Off-chain škálování {#offchain-scaling} -Off-chain řešení jsou implementována odděleně od Mainnetu vrstvy 1 – nevyžadují žádné změny v existujícím protokolu Etherea. Některá řešení, známá jako „řešení vrstvy 2“, odvozují svou bezpečnost přímo od konsensu vrstvy 1 Etherea, jako jsou [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/), [zero-knowledge rollupy](/developers/docs/scaling/zk-rollups/) nebo [stavové kanály](/developers/docs/scaling/state-channels/). Jiná řešení zahrnují vytvoření nových řetězců v různých formách, které řeší svoji bezpečnost nezávisle na Mainnetu, jako jsou [postranní řetězce](#sidechains), [validia](#validium) nebo [plazmatické řetězce](#plasma). Tato řešení komunikují s Mainnetem, ale odvozují svou bezpečnost odlišně, za účelem dosažení různých cílů. +Off-chain řešení jsou implementována odděleně od Mainnetu vrstvy 1 – nevyžadují žádné změny v existujícím protokolu Ethereum. Některá řešení, známá jako řešení „vrstvy 2“, odvozují svou bezpečnost přímo z konsensu Etherea na vrstvě 1, jako jsou [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/), [rollupy s nulovou znalostí](/developers/docs/scaling/zk-rollups/) nebo [stavové kanály](/developers/docs/scaling/state-channels/). Jiná řešení zahrnují vytváření nových chainů v různých formách, které odvozují svou bezpečnost nezávisle na Mainnetu, jako jsou [sidechainy](#sidechains), [validia](#validium) nebo [plasma chainy](#plasma). Tato řešení komunikují s Mainnetem, ale odvozují svou bezpečnost odlišně, za účelem dosažení různých cílů. ### Škálování vrstvy 2 {#layer-2-scaling} @@ -37,7 +37,7 @@ Tato kategorie off-chain řešení odvozuje svou bezpečnost od Mainnetu Etherea Vrstva 2 je souhrnný termín pro řešení navržená k lepšímu škálování vaší aplikace tím, že zpracovávají transakce mimo Mainnet Etherea (vrstva 1) a zároveň využívají robustní decentralizovaný bezpečnostní model Mainnetu. Rychlost transakcí trpí, když je síť zaneprázdněna, což zhoršuje uživatelský zážitek u určitých typů dappek. A jak se síť stává vytíženější, zvyšují se ceny paliva, protože odesílatelé transakcí se snaží navzájem předhánět. To může použití Etherea značně prodražit. -Většina řešení vrstvy 2 je založena na serveru nebo skupině serverů, z nichž každý může být označen jako síťový uzel, validátor, operátor, sekvencer, producent bloků nebo podobným termínem. V závislosti na implementaci mohou být tyto síťové uzly vrstvy 2 provozovány jednotlivci, podniky nebo subjekty, které je používají, nebo třetími stranami nebo velkou skupinou jednotlivců (podobně jako Mainnet). Obecně platí, že transakce jsou doručeny těmto uzlům vrstvy 2 namísto přímého doručení na vrstvu 1 (Mainnet). U některých řešení síťové uzly vrstvy 2 následně seskupují transakce do balíčků, které posléze ukotví na vrstvu 1, kde jsou právě touto vrstvou zabezpečeny a nelze je změnit. Detaily takové exekuce se mezi různými technologiemi a implementacemi vrstvy 2 značně liší. +Většina řešení vrstvy 2 je založena na serveru nebo skupině serverů, z nichž každý může být označen jako síťový uzel, validátor, operátor, sekvencer, producent bloků nebo podobným termínem. V závislosti na implementaci mohou být tyto síťové uzly vrstvy 2 provozovány jednotlivci, podniky nebo subjekty, které je používají, nebo třetími stranami nebo velkou skupinou jednotlivců (podobně jako Mainnet). Obecně platí, že transakce jsou doručeny těmto uzlům vrstvy 2 namísto přímého doručení na vrstvu 1 (Mainnet). U některých řešení instance vrstvy 2 dávkuje transakce do skupin, než je ukotví na vrstvu 1, načež jsou zabezpečeny vrstvou 1 a nelze je změnit. Detaily takové exekuce se mezi různými technologiemi a implementacemi vrstvy 2 značně liší. Konkrétní instance vrstvy 2 může být otevřená a sdílená mnoha aplikacemi nebo může být nasazena jedním projektem a určena pouze k podpoře jejich aplikace. @@ -48,7 +48,7 @@ Konkrétní instance vrstvy 2 může být otevřená a sdílená mnoha aplikacem - Jakékoli aktualizace škálovatelnosti by neměly být na úkor decentralizace nebo bezpečnosti – vrstva 2 je postavena nad Ethereem. - Existují sítě vrstvy 2 se specifickou aplikací, které přinášejí vlastní sadu efektivity při práci s aktivy ve velkém měřítku. -[Další informace o vrstvě 2](/layer-2/). +[Více o vrstvě 2](/layer-2/). #### Rollupy {#rollups} @@ -56,58 +56,58 @@ Rollupy provádějí exekuci transakcí mimo vrstvu 1 a poté data zveřejní na Existují dva typy rollupů s různými bezpečnostními modely: -- **Optimistické rollupy**: Předpokládají, že transakce jsou platné, a provádějí výpočet prostřednictvím [**důkazu podvodu**](/glossary/#fraud-proof) pouze v případě výzvy k ověření platnosti. [Více o optimistických rollupech](/developers/docs/scaling/optimistic-rollups/). -- **Zero-knowledge rollupy**: Provádějí výpočty mimo řetězec a předkládají [**důkaz o platnosti**](/glossary/#validity-proof) na řetězci. [Více o zero-knowledge rollupech](/developers/docs/scaling/zk-rollups/). +- **Optimistické rollupy**: předpokládají, že transakce jsou ve výchozím nastavení platné a spouští výpočet, prostřednictvím [**důkazu o podvodu**](/glossary/#fraud-proof), pouze v případě zpochybnění. [Více o optimistických rollupech](/developers/docs/scaling/optimistic-rollups/). +- **Rollupy s nulovou znalostí**: provádí výpočty off-chain a na chain odesílají [**důkaz o platnosti**](/glossary/#validity-proof). [Více o rollupech s nulovou znalostí](/developers/docs/scaling/zk-rollups/). #### Stavové kanály {#channels} -Stavové kanály využívají multisig kontrakty, aby účastníkům umožnili rychle a volně transakčně komunikovat mimo řetězec a poté finalizovat stav na Mainnetu. To minimalizuje přetížení sítě, poplatky a zpoždění. Dva typy kanálů jsou v současnosti stavové kanály a platební kanály. +Stavové kanály využívají multisig kontrakty, aby účastníkům umožnily rychle a volně provádět transakce off-chain, a poté finalizovat stav na Mainnetu. To minimalizuje přetížení sítě, poplatky a zpoždění. Dva typy kanálů jsou v současnosti stavové kanály a platební kanály. -Více o [stavových kanálech](/developers/docs/scaling/state-channels/). +Zjistěte více o [stavových kanálech](/developers/docs/scaling/state-channels/). -### Postranní řetězce {#sidechains} +### Sidechainy {#sidechains} Postranní řetězec je nezávislý blockchain kompatibilní s EVM, který běží paralelně s Mainnetem. Jsou kompatibilní s Ethereem prostřednictvím obousměrných přemostění a fungují podle svých vlastních pravidel konsensu a parametrů bloků. -Více o [postranních řetězcích](/developers/docs/scaling/sidechains/). +Zjistěte více o [sidechainech](/developers/docs/scaling/sidechains/). ### Plasma {#plasma} -Plazmový řetězec je samostatný blockchain, který je ukotven k hlavnímu řetězci Etherea a k řešení sporů používá důkazy podvodu (stejně jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)). +Plasma chain je samostatný blockchain, který je ukotven k hlavnímu chainu Etherea a používá důkazy o podvodu (stejně jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)) k řešení sporů. -Více o [Plasmě](/developers/docs/scaling/plasma/). +Zjistěte více o [Plasma](/developers/docs/scaling/plasma/). ### Validium {#validium} Řetězec typu validium používá důkazy o platnosti, stejně jako zero-knowledge rollupy, ale data nejsou uložena na vrstvě 1 Etherea. To umožňuje 10 000 transakcí za sekundu na jeden Validium řetězec a více řetězců může běžet paralelně. -Více o [Validiu](/developers/docs/scaling/validium/). +Zjistěte více o [Validium](/developers/docs/scaling/validium/). ## Proč je potřeba tolik škálovacích řešení? {#why-do-we-need-these} - Více řešení může pomoci snížit celkové přetížení na jakékoliv části sítě a také zabránit vzniku jediných bodů selhání. - Celek je efektivnější než součet efektivity jeho částí. Různá řešení mohou existovat a pracovat v harmonii, což aplikuje exponenciální efekt na budoucí rychlost transakcí a propustnost. - Ne všechna řešení vyžadují přímé využití konsensuálního algoritmu Etherea a alternativy mohou nabízet výhody, které by jinak bylo obtížné získat. -- Žádné jedno škálovací řešení samo o sobě nestačí k naplnění [vize Etherea](/roadmap/vision/). -## Učíte se spíše vizuálně? {#visual-learner} +## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} -_Upozornění: Ve videu je pojem „Vrstva 2“ používán k označení všech off-chain škálovacích řešení, zatímco my rozlišujeme „vrstvu 2“ jako off-chain řešení, které odvozuje svou bezpečnost od konsensu vrstvy 1 Mainnetu._ +_Upozornění: Vysvětlení ve videu používá termín „vrstva 2“ k označení všech off-chain řešení škálování, zatímco my rozlišujeme „vrstvu 2“ jako off-chain řešení, které odvozuje svou bezpečnost prostřednictvím konsensu Mainnetu vrstvy 1._ -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [A rollup-centric Ethereum roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) – _Vitalik Buterin_ -- [Aktuální analytika škálovacích řešení vrstvy 2 pro Ethereum](https://www.l2beat.com/) -- [Hodnocení škálovacích řešení vrstvy 2 pro Ethereum: Porovnávací rámec](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [Plán Etherea zaměřený na rollupy](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ +- [Aktuální analýzy řešení škálování vrstvy 2 pro Ethereum](https://www.l2beat.com/) +- [Hodnocení řešení škálování vrstvy 2 pro Ethereum: Srovnávací rámec](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) - [Neúplný průvodce rollupy](https://vitalik.eth.limo/general/2021/01/05/rollup.html) -- [Ethereum-powered ZK-Rollups: Světoví šampioni](https://hackmd.io/@canti/rkUT0BD8K) -- [Optimistické rollupy vs ZK Rollupy](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) -- [Proč jsou rollupy + data shards jediným udržitelným řešením vysoké škálovatelnosti](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) -- [Jaké vrstvy 3 dávají smysl?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) -- [Dostupnost dat: Jak se rollupy přestaly bát a začaly milovat Ethereum](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) - -_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ji!_ +- [ZK-Rollupy na Ethereu: Světová špička](https://hackmd.io/@canti/rkUT0BD8K) +- [Optimistické rollupy vs. ZK rollupy](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [Proč jsou rollupy a datové shardy jediným udržitelným řešením pro vysokou škálovatelnost](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [Jaký druh vrstev 3 dává smysl?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [Dostupnost dat aneb: Jak se rollupy naučily nedělat si starosti a milovat Ethereum](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [Praktický průvodce rollupy na Ethereu](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) + +_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/scaling/optimistic-rollups/index.md b/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md index 966d0625f8c..b8bc8f49c07 100644 --- a/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md @@ -1,16 +1,16 @@ --- -title: Optimistické rollupy -description: Úvod do optimistických rollapů – řešení pro škálování, které používá komunita Etherea. +title: "Optimistické rollupy" +description: "Úvod do optimistických rollapů – řešení pro škálování, které používá komunita Etherea." lang: cs --- -Optimistické rollupy jsou protokoly druhé vrstvy (L2) navržené k rozšíření propustnosti základní vrstvy Etherea. Snižují výpočetní zátěž na hlavním řetězci Ethereua tím, že zpracovávají transakce mimo řetězec, což vede k významnému zlepšení rychlosti jejich zpracování. Na rozdíl od jiných škálovacích řešení, jako jsou [sidechainy](/developers/docs/scaling/sidechains/), využívají optimistické rollupy bezpečnost Mainnetu tím, že zveřejňují výsledky transakcí na řetězci, podobně jako [plasma chainy](/developers/docs/scaling/plasma/), které také ověřují transakce na Ethereu pomocí důkazů podvodů, ale ukládají data transakcí jinde. +Optimistické rollupy jsou protokoly druhé vrstvy (L2) navržené k rozšíření propustnosti základní vrstvy Etherea. Snižují výpočetní zátěž na hlavním řetězci Etherea tím, že zpracovávají transakce mimo řetězec, což vede k významnému zlepšení rychlosti jejich zpracování. Na rozdíl od jiných škálovacích řešení, jako jsou [sidechainy](/developers/docs/scaling/sidechains/), využívají optimistické rollupy bezpečnost Mainnetu tím, že zveřejňují výsledky transakcí na řetězci, podobně jako [plasma chainy](/developers/docs/scaling/plasma/), které také ověřují transakce na Ethereu pomocí důkazů podvodů, ale ukládají data transakcí jinde. -Protože výpočty jsou pomalou a nákladnou součástí používání Etherea, mohou optimistické rollupy nabídnout 10x až 100x lepší škálovatelnost. Optimistické rollupy také zapisují transakce na Ethereum jako `calldata` nebo v [blobech](/roadmap/danksharding/), což uživatelům snižuje náklady na transakce. +Protože výpočty jsou pomalou a nákladnou součástí používání Etherea, mohou optimistické rollupy nabídnout 10x až 100x lepší škálovatelnost. Optimistické rollupy také zapisují transakce na Ethereum jako `calldata` nebo v [blobech](/roadmap/danksharding/), což uživatelům snižuje náklady na palivo. ## Předpoklady {#prerequisites} -Měli byste si přečíst a porozumět našim stránkám o [škálování Etherea](/developers/docs/scaling/) a [druhé vrstvě](/layer-2/). +Měli byste mít přečteny naše stránky o [škálování Etherea](/developers/docs/scaling/) a [vrstvě 2](/layer-2/). ## Co je to optimistický rollup? {#what-is-an-optimistic-rollup} @@ -18,7 +18,7 @@ Optimistický rollup je přístup ke škálování Etherea, který zahrnuje pře Operátoři optimistických rollupů seskupují více transakcí mimo řetězec do velkých balíčků, které následně odesílají na Ethereum. Tento přístup umožňuje rozložit fixní náklady mezi více transakcí v každém balíčku, což snižuje poplatky pro koncové uživatele. Optimistické rollupy ke snížení množství dat zveřejňovaných na Ethereum využívají i kompresní techniky. -Optimistické rollupy jsou považovány za „optimistické“, protože předpokládají, že transakce mimo řetězec jsou platné a nezveřejňují důkazy o platnosti balíčků transakcí zveřejněných na řetězci. Tím se optimistické rollupy liší od rollupů s [nulovou znalostí (zero-knowledge rollups)](/developers/docs/scaling/zk-rollups), které zveřejňují kryptografické důkazy o platnosti transakcí mimo řetězec. +Optimistické rollupy jsou považovány za „optimistické“, protože předpokládají, že transakce mimo řetězec jsou platné a nezveřejňují důkazy o platnosti balíčků transakcí zveřejněných na řetězci. Tím se optimistické rollupy liší od [rollupů s nulovou znalostí](/developers/docs/scaling/zk-rollups), které zveřejňují kryptografické [důkazy o platnosti](/glossary/#validity-proof) pro transakce mimo řetězec. Místo toho se optimistické rollupy spoléhají na schéma prokázání podvodu (fraud-proving scheme), aby zjistily případy, kdy nejsou transakce správně vypočteny. Poté, co rollup odešle balíček na Ethereum, začne běžet časové okno (nazývané doba výzvy), během kterého může kdokoliv zpochybnit výsledky transakce rollupu vypočtením [důkazu podvodu](/glossary/#fraud-proof). @@ -26,29 +26,29 @@ Pokud důkaz podvodu uspěje, protokol rollupu transakce znovu provede a podle t Pokud balíček rollupu zůstane bez výzvy (tj. všechny transakce jsou správně provedeny) po skončení časového okna, je považován za platný a přijatý na Ethereum. Ostatní mohou nadále stavět na nepotvrzeném bloku rollupu, ale s podmínkou: Výsledky transakcí budou zrušeny, pokud budou založeny na nesprávně provedené transakci. -## Jak optimistické rollupy interagují s Ethereum? {#optimistic-rollups-and-Ethereum} +## Jak optimistické rollupy interagují s Ethereum? Jak optimistické rollupy škálují Ethereum? {#optimistic-rollups-and-Ethereum} -Optimistické rollupy jsou [řešení pro škálování mimo řetězec](/developers/docs/scaling/#off-chain-scaling) navržená k provozu nad Ethereum. Každý optimistický rollup je spravován sadou smart kontraktů nasazených na síti Ethereum. Optimistické rollupy zpracovávají transakce mimo hlavní řetězec Ethereum, ale odesílají transakce mimo řetězec (v balíčcích) do rollupového kontraktu na řetězci. Stejně jako blockchain Ethereum je tento záznam transakcí neměnný a tvoří „optimistický rollupový řetězec“. +Optimistické rollupy jsou [řešení pro škálování mimo řetězec](/developers/docs/scaling/#offchain-scaling) navržená k provozu nad Ethereem. Každý optimistický rollup je spravován sadou smart kontraktů nasazených na síti Ethereum. Optimistické rollupy zpracovávají transakce mimo hlavní řetězec Ethereum, ale odesílají transakce mimo řetězec (v balíčcích) do rollupového kontraktu na řetězci. Stejně jako blockchain Ethereum je tento záznam transakcí neměnný a tvoří „optimistický rollupový řetězec“. Architektura optimistického rollupu se skládá z následujících částí: -**On-chain kontrakty**: Provoz optimistických rollupů je řízen smart kontrakty běžícími na Ethereu. To zahrnuje kontrakty, které ukládají bloky rollupu, monitorují aktualizace stavu na rollupu a sledují vklady uživatelů. V tomto smyslu slouží Ethereum jako základní vrstva nebo „vrstva 1“ pro optimistické rollupy. +**Kontrakty na řetězci**: Provoz optimistických rollupů je řízen chytrými kontrakty běžícími na Ethereu. To zahrnuje kontrakty, které ukládají bloky rollupu, monitorují aktualizace stavu na rollupu a sledují vklady uživatelů. V tomto smyslu slouží Ethereum jako základní vrstva nebo „vrstva 1“ pro optimistické rollupy. -**Off-chain virtuální stroj (VM)**: Ačkoliv kontrakty spravující protokol optimistických rollupů běží na Ethereu, protokol rollupu provádí výpočty a ukládání stavu na jiném virtuálním stroji, odděleném od [Virtuálního stroje Etherea](/developers/docs/evm/). Off-chain VM je místem, kde žijí aplikace a kde jsou prováděny změny stavu; slouží jako horní vrstva nebo „vrstva 2“ pro optimistický rollup. +**Virtuální stroj (VM) mimo řetězec**: Ačkoliv kontrakty spravující protokol optimistických rollupů běží na Ethereu, protokol rollupu provádí výpočty a ukládání stavu na jiném virtuálním stroji, odděleném od [Virtuálního stroje Etherea](/developers/docs/evm/). VM mimo řetězec je místem, kde žijí aplikace a kde jsou prováděny změny stavu; slouží jako horní vrstva nebo „vrstva 2“ pro optimistický rollup. -Protože optimistické rollupy jsou navrženy tak, aby spouštěly programy buď psané, nebo kompilované pro EVM, off-chain VM obsahuje mnoho specifikací návrhu EVM. Navíc důkazy podvodu vypočítané na řetězci umožňují síti Ethereum vynucovat platnost změn stavů vypočítaných v off-chain VM. +Protože optimistické rollupy jsou navrženy tak, aby spouštěly programy buď psané, nebo kompilované pro EVM, VM mimo řetězec obsahuje mnoho specifikací návrhu EVM. Navíc důkazy podvodu vypočítané na řetězci umožňují síti Ethereum vynucovat platnost změn stavů vypočítaných ve VM mimo řetězec. -Optimistické rollupy jsou popisovány jako „hybridní škálovací řešení“, protože, ačkoliv existují jako samostatné protokoly, jejich bezpečnostní vlastnosti jsou odvozeny od Etherea. Ethereum zaručuje kromě jiného správnost výpočtů mimo řetězec a dostupnost dat za těmito výpočty. To činí optimistické rollupy bezpečnějšími než čistě off-chain škálovací protokoly (např. [sidechainy](/developers/docs/scaling/sidechains/)), které se pro zajištění bezpečnosti nespoléhají na Ethereum. +Optimistické rollupy jsou popisovány jako „hybridní škálovací řešení“, protože, ačkoliv existují jako samostatné protokoly, jejich bezpečnostní vlastnosti jsou odvozeny od Etherea. Ethereum zaručuje kromě jiného správnost výpočtů rollupu mimo řetězec a dostupnost dat za těmito výpočty. To činí optimistické rollupy bezpečnějšími než čistě škálovací protokoly mimo řetězec (např. [sidechainy](/developers/docs/scaling/sidechains/)), které se pro zajištění bezpečnosti nespoléhají na Ethereum. Optimistické rollupy se spoléhají na hlavní protokol Etherea z následujících důvodů: ### Dostupnost dat {#data-availability} -Jak již bylo zmíněno, optimistické rollupy zveřejňují data transakcí na Ethereu jako `calldata` nebo v [blobech](/roadmap/danksharding/). Jelikož je exekuce řetězce rollupu založena na odeslaných transakcích, kdokoli může využít tyto informace – uložené na základní vrstvě Etherea – k vykonání stavu rollupu a ověření správnosti změn stavů. +Jak již bylo zmíněno, optimistické rollupy posílají data transakcí na Ethereum jako `calldata` nebo v [blobech](/roadmap/danksharding/). Jelikož je exekuce řetězce rollupu založena na odeslaných transakcích, kdokoli může využít tyto informace – uložené na základní vrstvě Etherea – k vykonání stavu rollupu a ověření správnosti změn stavů. [Dostupnost dat](/developers/docs/data-availability/) je klíčová, protože bez přístupu k datům o stavu nemohou vyzyvatelé sestavit důkaz podvodu, aby zpochybnili neplatné operace rollupu. Díky tomu, že Ethereum poskytuje dostupnost dat, riziko, že se operátorům rollupů podaří uniknout se zlomyslnými činy (např. odeslání neplatných bloků), se snižuje. -### Odolnost proti cenzuře {#censorship-resistance} +### Odolnost vůči cenzuře {#censorship-resistance} Optimistické rollupy se také spoléhají na Ethereum v otázce odolnosti proti cenzuře. V optimistickém rollupu je centralizovaná entita (operátor) odpovědná za zpracování transakcí a odesílání bloků rollupu na Ethereum. To má několik důsledků: @@ -64,7 +64,7 @@ Optimistické rollupy řeší tento problém tím, že nutí operátory zveřej - Uživatelé mohou také odesílat své transakce na L1 místo na sekvencer, v takovém případě musí sekvencer transakci zahrnout do určitého časového limitu, aby mohl pokračovat ve vytváření platných bloků. -### Vyrovnání {#settlement} +### Vypořádání {#settlement} Další rolí Etherea v kontextu optimistických rollupů je role vyrovnávací vrstvy. Ta ukotvuje celý ekosystém blockchainu, zajišťuje bezpečnost a poskytuje objektivní finalitu v případě, že dojde ke sporu na jiném řetězci (v tomto případě optimistických rollupech), který vyžaduje arbitráž. @@ -72,29 +72,29 @@ Ethereum Mainnet poskytuje centrum pro ověřování důkazů podvodu a řešen ## Jak fungují optimistické rollupy? {#how-optimistic-rollups-work} -### Exekuce a agregace transakcí {#transaction-execution-and-aggregation} +### Provedení a agregace transakcí {#transaction-execution-and-aggregation} Uživatelé odesílají transakce „operátorům“, což jsou síťové uzly odpovědné za zpracování transakcí na optimistickém rollupu. Operátor, také známý jako „validátor“ nebo „agregátor“, agreguje transakce, komprimuje podkladová data a zveřejňuje bloky na Ethereu. -Ačkoli se validátorem může stát kdokoli, validátoři optimistických rollupů musí před vytvořením bloků složit zálohu, podobně jako v [systému proof of stake](/developers/docs/consensus-mechanisms/pos/). Z této zálohy může být zaplacena pokuta, pokud validátor zveřejní neplatný blok nebo postaví na starém, ale neplatném bloku (i když jeho blok platný je). Tímto způsobem optimistické rollupy využívají kryptografické ekonomické pobídky k zajištění poctivého chování validátorů. +Ačkoli se validátorem může stát kdokoli, validátoři optimistických rollupů musí před vytvořením bloků složit zálohu, podobně jako v [systému s důkazem podílu](/developers/docs/consensus-mechanisms/pos/). Z této zálohy může být zaplacena pokuta, pokud validátor zveřejní neplatný blok nebo postaví na starém, ale neplatném bloku (i když jeho blok platný je). Tímto způsobem optimistické rollupy využívají kryptografické ekonomické pobídky k zajištění poctivého chování validátorů. Ostatní validátoři na řetězci optimistického rollupu mají za úkol exekuovat odeslané transakce pomocí své kopie stavu rollupu. Pokud se konečný stav validátora liší od navrhovaného stavu operátora, mohou zahájit výzvu a vypočítat důkaz podvodu. Některé optimistické rollupy mohou upustit od systému validátorů bez povolení a k exekuci řetězce použít jediný „sekvencer“. Stejně jako validátor zpracovává sekvencer transakce, vytváří bloky rollupu a odesílá transakce rollupu na řetězec L1 (Ethereum). -Sekvencer se liší od běžného operátora rollupu tím, že má větší kontrolu nad pořadím transakcí. Také má prioritní přístup k řetězci rollupu a je jediným subjektem, který je oprávněn odesílat transakce do on-chain kontraktu. Transakce ze síťových uzlů, které nejsou sekvencery, nebo od běžných uživatelů jsou jednoduše zařazeny do samostatné fronty, dokud je sekvencer nezahrne do nového balíčku. +Sekvencer se liší od běžného operátora rollupu tím, že má větší kontrolu nad pořadím transakcí. Sekvencer má také prioritní přístup k řetězci rollupu a je jediným subjektem oprávněným odesílat transakce do kontraktu na řetězci. Transakce ze síťových uzlů, které nejsou sekvencery, nebo od běžných uživatelů jsou jednoduše zařazeny do samostatné fronty, dokud je sekvencer nezahrne do nového balíčku. #### Odesílání bloků rollupu na Ethereum {#submitting-blocks-to-ethereum} Jak již bylo zmíněno, operátor optimistického rollupu seskupuje transakce mimo řetězec do balíčku a odesílá jej na Ethereum za účelem ověření. Tento proces zahrnuje kompresi dat souvisejících s transakcemi a jejich zveřejnění na Ethereu jako `calldata` nebo v blobech. -`Calldata` je nemodifikovatelná a nepersistentní oblast ve smart kontraktu, která se většinou chová jako [paměť](/developers/docs/smart-contracts/anatomy/#memory). Zatímco `calldata` zůstávají na řetězci jako součást [historických záznamů blockchainu](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs), nejsou uložena jako součást stavu Etherea. Protože `calldata` se nedotýkají žádné části stavu Etherea, jsou levnější než stav pro ukládání dat na řetězci. +`calldata` je nemodifikovatelná a nepersistentní oblast v chytrém kontraktu, která se většinou chová jako [paměť](/developers/docs/smart-contracts/anatomy/#memory). I když `calldata` přetrvává na řetězci jako součást [historických záznamů](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) blockchainu, neukládá se jako součást stavu Etherea. Protože se `calldata` nedotýká žádné části stavu Etherea, je levnější než stav pro ukládání dat na řetězci. -Klíčové slovo `calldata` se také používá v jazyce Solidity k předání argumentů funkci smart kontraktu během jeho exekuce. `calldata` identifikuje funkci, která je volána během transakce, a drží vstupy pro tuto funkci ve formě libovolné sekvence bytů. +Klíčové slovo `calldata` se také používá v Solidity k předání argumentů funkci chytrého kontraktu během její exekuce. `calldata` identifikuje funkci, která je volána během transakce, a drží vstupy pro tuto funkci ve formě libovolné sekvence bytů. -V kontextu optimistických rollupů se `calldata` používá k odesílání komprimovaných dat transakcí do on-chain kontraktu. Operátor rollupu přidá nový balíček tím, že zavolá požadovanou funkci v kontraktu rollupu a předá komprimovaná data jako argumenty funkce. Použití `calldata` snižuje poplatky pro uživatele, protože většina nákladů, které rollupy přinášejí, pochází z ukládání dat na řetězci. +V kontextu optimistických rollupů se `calldata` používá k odesílání komprimovaných dat transakcí do kontraktu na řetězci. Operátor rollupu přidá nový balíček tím, že zavolá požadovanou funkci v kontraktu rollupu a předá komprimovaná data jako argumenty funkce. Použití `calldata` snižuje poplatky pro uživatele, protože většina nákladů, které rollupy přinášejí, pochází z ukládání dat na řetězci. -Zde je [příklad](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) odeslání balíčku rollupu, který ukazuje, jak tento koncept funguje. Sekvencer vyvolal `metodu appendSequencerBatch()` a předal komprimovaná data transakcí jako vstupy pomocí `calldata`. +Zde je [příklad](https://eth.blockscout.com/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) odeslání dávky rollupu, který ukazuje, jak tento koncept funguje. Sekvencer vyvolal metodu `appendSequencerBatch()` a předal komprimovaná data transakcí jako vstupy pomocí `calldata`. Některé rollupy nyní používají k odesílání balíčků transakcí na Ethereum bloby. @@ -102,15 +102,15 @@ Bloby jsou nemodifikovatelné a nepersistentní (stejně jako `calldata`), ale j ### Závazky stavu {#state-commitments} -V každém časovém bodě je stav optimistického rollupu (účty, zůstatky, kód kontraktu atd.) organizován jako [Merkle tree](/whitepaper/#merkle-trees), nazývaný „strom stavu“. Kořen tohoto Merkle tree (state root), který odkazuje na nejnovější stav rollupu, je hashován a uložen v kontraktu rollupu. Každý přechod stavu na řetězci produkuje nový stav rollupu, ke kterému se operátor zavazuje tím, že vypočítá nový state root. +V každém časovém bodě je stav optimistického rollupu (účty, zůstatky, kód kontraktu atd.) organizován jako [Merkle tree](/whitepaper/#merkle-trees) nazývaný „strom stavu“. Kořen tohoto Merkle tree (state root), který odkazuje na nejnovější stav rollupu, je hashován a uložen v kontraktu rollupu. Každý přechod stavu na řetězci produkuje nový stav rollupu, ke kterému se operátor zavazuje tím, že vypočítá nový state root. -Operátor je povinen odeslat jak staré, tak nové state roots při zveřejňování balíčků. Pokud starý state root odpovídá stávajícímu state rootu v on-chain kontraktu, je vyřazen a nahrazen novým state rootem. +Operátor je povinen odeslat jak staré, tak nové state roots při zveřejňování balíčků. Pokud starý kořen stavu odpovídá stávajícímu kořenu stavu v kontraktu na řetězci, je tento vyřazen a nahrazen novým kořenem stavu. Operátor rollupu je také povinen se zavázat k Merkle kořeni samotného balíčku transakcí. To komukoliv umožňuje prokázat zahrnutí transakce do balíčku (na L1) předložením [Merkle důkazu](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). Závazky stavu, zejména state roots, jsou nezbytné pro prokázání správnosti změn stavu v optimistickém rollupu. Rollupový kontrakt přijímá nové state rooty od operátorů okamžitě po jejich odeslání, ale později může odstranit neplatné state rooty, aby obnovil správný stav rollupu. -### Prokazování podvodu {#fraud-proving} +### Dokazování podvodu {#fraud-proving} Jak bylo vysvětleno, optimistické rollupy umožňují komukoli zveřejňovat bloky bez poskytnutí důkazů o platnosti. Aby se však zajistilo, že řetězec zůstane bezpečný, optimistické rollupy určují časové okno, během kterého může kdokoliv zpochybnit změnu stavu. Bloky rollupu se proto nazývají „tvrzení“, protože jejich platnost může kdokoliv zpochybnit. @@ -120,7 +120,7 @@ Schémata interaktivního prokazování v jednom kole znovu přehrají sporné t Opětovné provádění transakcí na L1 k detekci podvodu však vyžaduje zveřejnění závazků stavu pro jednotlivé transakce a zvyšuje množství dat, která musí rollupy na řetězci zveřejnit. Opakování transakcí také přináší významné náklady na palivo. Z těchto důvodů přecházejí optimistické rollupy na interaktivní prokazování ve více kolech, které dosahuje stejného cíle (tj. detekování neplatných operací rollupu) s větší efektivitou. -#### Vícekolové interaktivní prokazování {#multi-round-interactive-proving} +#### Vícekolové interaktivní dokazování {#multi-round-interactive-proving} Vícekolové interaktivní prokazování zahrnuje protokol vzájemného dialogu mezi prosazovatelem a vyzyvatelem, který je řízen verifikačním kontraktem na L1, jenž nakonec rozhoduje o tom, která strana lže. Po zpochybnění tvrzení uzlem L2 je asserter povinen rozdělit sporné tvrzení na dvě stejné poloviny. Každé jednotlivé tvrzení v tomto případě obsahuje stejné množství kroků výpočtu jako druhé. @@ -132,7 +132,7 @@ Uvádíme také několik poznámek k tomuto typu důkazu podvodu: 1. Vícekolové interaktivní prokazování podvodu je považováno za efektivní, protože minimalizuje práci, kterou musí L1 řetězec vykonat při arbitráži sporu. Místo replikace celé transakce musí L1 řetězec znovu provést pouze jeden krok v exekuci rollupu. -2. Bisekční protokoly snižují množství dat zveřejněných na řetězi (není třeba zveřejňovat závazky stavu pro každou transakci). Kromě toho nejsou transakce optimistických rollupů omezeny limitem paliva Etherea. Naopak při opětovném provádění transakcí musí optimistické rollupy zajistit, aby transakce na L2 měly nižší limit paliva, aby mohly napodobovat svoji exekuci v rámci jedné transakce na Ethereu. +2. Bisekční protokoly snižují množství dat zveřejněných na řetězci (není třeba zveřejňovat závazky stavu pro každou transakci). Kromě toho nejsou transakce optimistických rollupů omezeny limitem paliva Etherea. Naopak při opětovném provádění transakcí musí optimistické rollupy zajistit, aby transakce na L2 měly nižší limit paliva, aby mohly napodobovat svoji exekuci v rámci jedné transakce na Ethereu. 3. Část zálohy zlovolného prosazovatele je převedena vyzyvateli, zatímco druhá část je spálena. Tím se předchází tajné dohodě mezi validátory; pokud by dva validátoři kolaborovali a zahájili falešné výzvy, stále by ztratili značnou část celé zástavy. @@ -146,17 +146,17 @@ Zlovolné uzly se mohou pokusit o zdržení potvrzení platného bloku rollupu z Tato vlastnost souvisí také s další bezpečnostní vlastností optimistických rollupů: platnost řetězce závisí na existenci _jednoho_ poctivého uzlu. Poctivý uzel může řetězec správně rozvíjet buď tím, že zveřejní platná tvrzení, nebo zpochybní neplatná tvrzení. V každém případě zlovolné uzly, které vstoupí do sporu s poctivým uzlem, během procesu prokazování podvodu přijdou o své zástavy. -### Interoperabilita mezi L1 a L2 {#l1-l2-interoperability} +### Interoperabilita L1/L2 {#l1-l2-interoperability} -Optimistické rollupy jsou navrženy pro interoperabilitu s Ethereum Mainnetem a umožňují uživatelům přenášet zprávy a libovolná data mezi L1 a L2. Jsou také kompatibilní s EVM, takže můžete přenést [existující dappky](/developers/docs/dapps/) na optimistické rollupy nebo pomocí vývojových nástrojů Etherea vytvořit nové dappky. +Optimistické rollupy jsou navrženy pro interoperabilitu s Ethereum Mainnetem a umožňují uživatelům přenášet zprávy a libovolná data mezi L1 a L2. Jsou také kompatibilní s EVM, takže můžete přenést existující [dapps](/developers/docs/dapps/) na optimistické rollupy nebo pomocí vývojových nástrojů Etherea vytvořit nové dapps. -#### 1. Pohyb aktiv {#asset-movement} +#### 1. Přesun aktiv {#asset-movement} ##### Vstup do rollupu Pro použití optimistického rollupu uživatelé vkládají ETH, ERC-20 tokeny a další přijatá aktiva do kontraktu [přemostění](/developers/docs/bridges/) příslušného rollupu na L1. Toto přemostění přenese transakci na L2, kde je ekvivalentní množství aktiv vyraženo a odesláno na vybranou adresu uživatele na optimistickém rollupu. -Uživatelem generované transakce (jako je vklad L1 > L2) jsou obvykle zařazeny do fronty, dokud je sekvencer znovu neodešle do kontraktu rollupu. Nicméně aby se zachovala odolnost proti cenzuře, optimistické rollupy umožňují uživatelům odeslat transakci přímo do on-chain kontraktu rollupu, pokud byla zpožděna o více než je maximální povolený čas. +Uživatelem generované transakce (jako je vklad L1 > L2) jsou obvykle zařazeny do fronty, dokud je sekvencer znovu neodešle do kontraktu rollupu. Nicméně aby se zachovala odolnost proti cenzuře, optimistické rollupy umožňují uživatelům odeslat transakci přímo do kontraktu rollupu na řetězci, pokud byla zpožděna o více než je maximální povolený čas. Některé optimistické rollupy přijímají jednodušší přístup k zabránění cenzurování uživatelů ze strany sekvencerů. V takovém případě je blok definován všemi transakcemi odeslanými do L1 kontraktu od předchozího bloku (např. vklady) spolu s transakcemi zpracovanými na řetězci rollupu. Pokud sekvencer ignoruje transakci na L1, zveřejní (prokazatelně) nesprávný state root; proto sekvencery nemohou zpožďovat uživatelem generované zprávy, jakmile jsou zveřejněny na L1. @@ -166,7 +166,7 @@ Výběr z optimistického rollupu na Ethereu je složitější kvůli schématu Po zahájení požadavku na výběr na L2 rollupu je transakce zahrnuta do dalšího balíčku, zatímco aktiva uživatele na rollupu jsou spálena. Jakmile je balíček zveřejněn na Ethereu, může uživatel vypočítat Merkle důkaz prokazující zahrnutí jejich výstupní transakce do bloku. Poté už jen zbývá počkat, až uplyne doba zpoždění, aby mohla být transakce na L1 finalizována a prostředky vybrány na Mainnet. -Aby se uživatelé optimistických rollupů vyhnuli čekání na týdenní výběr prostředků na Ethereum, mohou využít **poskytovatele likvidity** (LP). Poskytovatel likvidity převezme vlastnictví čekajícího výběru na L2 a vyplatí uživateli prostředky na L1 (za poplatek). +Aby se uživatelé optimistických rollupů vyhnuli týdennímu čekání na výběr prostředků na Ethereum, mohou využít **poskytovatele likvidity** (LP). Poskytovatel likvidity převezme vlastnictví čekajícího výběru na L2 a vyplatí uživateli prostředky na L1 (za poplatek). Poskytovatelé likvidity mohou před uvolněním prostředků ověřit platnost požadavku na výběr uživatele (tím, že sami exekuují řetězec). Tímto způsobem mají jistotu, že transakce bude nakonec potvrzena (tj. dojde k dosažení důvěryhodné finality). @@ -182,7 +182,7 @@ ii. Vývojáři a projektové týmy používající optimistické rollupy mohou Použití existujících nástrojů je důležité, protože tyto nástroje byly během let důkladně auditovány, laděny a vylepšovány. Rovněž to eliminuje potřebu, aby se vývojáři Etherea učili pracovat s úplně novou vývojovou sadou. -#### 3. Meziblockchainové volání kontraktů {#cross-chain-contract-calls} +#### 3. Volání kontraktů mezi řetězci {#cross-chain-contract-calls} Uživatelé (externě vlastněné účty) interagují s kontrakty na L2 tak, že odešlou transakci do kontraktu rollupu nebo to za ně udělá sekvencer či validátor. Optimistické rollupy také umožňují kontraktům na Ethereu interagovat s kontrakty na L2 pomocí kontraktů přemostění, které přenášejí zprávy a data mezi L1 a L2. To znamená, že můžete naprogramovat L1 kontrakt na Ethereum Mainnetu, aby volal funkce náležící kontraktům na L2 optimistickém rollupu. @@ -190,17 +190,17 @@ Meziblockchainové volání kontraktů probíhá asynchronně – tj. volání j Příkladem meziblockchainového volání kontraktů je dříve popsaný vklad tokenů. Kontrakt na L1 uschová tokeny uživatele a pošle zprávu spárovanému kontraktu na L2, aby na rollupu vydal odpovídající množství tokenů. -Jelikož cross-chain volání zpráv vede k exekuci kontraktu, odesílatel je obvykle povinen pokrýt [náklady na palivo](/developers/docs/gas/) za tento výpočet. Doporučuje se nastavit vysoký limit paliva, aby se předešlo selhání transakce na cílovém řetězci. Scénář přemostění tokenů je dobrým příkladem; pokud L1 část transakce (vklad tokenů) funguje, ale L2 část (vydání nových tokenů) selže kvůli nízkému limitu paliva, vklad se stává nevratně ztraceným. +Jelikož volání zpráv mezi řetězci vede k exekuci kontraktu, odesílatel je obvykle povinen pokrýt [náklady na palivo](/developers/docs/gas/) za tento výpočet. Doporučuje se nastavit vysoký limit paliva, aby se předešlo selhání transakce na cílovém řetězci. Scénář přemostění tokenů je dobrým příkladem; pokud L1 část transakce (vklad tokenů) funguje, ale L2 část (vydání nových tokenů) selže kvůli nízkému limitu paliva, vklad se stává nevratně ztraceným. -Je třeba poznamenat, že zprávy L2 > L1 mezi kontrakty musí počítat se zpožděním (zprávy L1 > L2 jsou obvykle vykonány po několika minutách). To proto, že zprávy zaslané na Mainnet z optimistického rollupu nelze vykonat, dokud neuplyne okno, během kterého je možné podat výzvu. +Na závěr je třeba poznamenat, že volání zpráv L2 > L1 mezi kontrakty musí počítat se zpožděním (volání L1 > L2 jsou obvykle vykonána po několika minutách). To proto, že zprávy zaslané na Mainnet z optimistického rollupu nelze vykonat, dokud neuplyne okno, během kterého je možné podat výzvu. ## Jak fungují poplatky na optimistických rollupech? {#how-do-optimistic-rollup-fees-work} Optimistické rollupy používají systém poplatků za palivo podobně jako Ethereum, aby bylo možné vyčíslit, kolik uživatelé platí za transakci. Poplatky účtované u optimistických rollupů závisí na následujících složkách: -1. **Zápis stavu**: Optimistické rollupy posílají data transakcí a hlavičky bloků (sestávající z hashe hlavičky předchozího bloku, state rootu a batch rootu) na Ethereum jako `blob` nebo „velký binární objekt“. [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) zavedl nákladově efektivní řešení pro zahrnutí dat na řetězec. `Blob` je nové pole transakce, které umožňuje rollupům zveřejnit komprimovaná data o přechodu stavu na Ethereum L1. Na rozdíl od `calldata`, které zůstává na řetězi trvale, jsou bloby krátkodobé a mohou být odstraněny z klientů po [4 096 epochách](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (přibližně 18 dnech). Použitím blobů pro zveřejnění balíčků komprimovaných transakcí mohou optimistické rollupy výrazně snížit náklady na zápis transakcí na L1. +1. **Zápis stavu**: Optimistické rollupy posílají data transakcí a hlavičky bloků (sestávající z haše hlavičky předchozího bloku, kořenu stavu, kořenu dávky) na Ethereum jako `blob` nebo „velký binární objekt“. [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) zavedl nákladově efektivní řešení pro zahrnutí dat na řetězec. Blob je nové pole transakce, které umožňuje rollupům zveřejnit komprimovaná data o přechodu stavu na Ethereum L1. Na rozdíl od `calldata`, které zůstávají trvale na řetězci, jsou bloby krátkodobé a mohou být odstraněny z klientů po [4096 epochách](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (přibližně 18 dní). Použitím blobů pro zveřejnění balíčků komprimovaných transakcí mohou optimistické rollupy výrazně snížit náklady na zápis transakcí na L1. -2. **Palivo spotřebované blobem**: Transakce s blobem používají dynamický mechanismus poplatků podobný tomu, který byl zaveden [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Poplatek za palivo pro typ-3 transakce zohledňuje základní poplatek za bloby, který je určen sítí na základě poptávky po blobovém prostoru a využití blobového prostoru transakcí, která je odesílána. +2. **Spotřebované palivo blobu**: Transakce přenášející bloby používají dynamický mechanismus poplatků podobný tomu, který byl zaveden v [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). Poplatek za palivo pro typ-3 transakce zohledňuje základní poplatek za bloby, který je určen sítí na základě poptávky po blobovém prostoru a využití blobového prostoru transakcí, která je odesílána. 3. **Poplatky operátorů L2**: Toto je částka zaplacená síťovým uzlům rollupu jako kompenzace za výpočetní náklady vzniklé při zpracování transakcí, podobně jako poplatky za palivo na Ethereu. Uzel rollupu účtuje nižší transakční poplatky, protože L2 má vyšší kapacitu zpracování a není konfrontován s přetížením sítě, které nutí validátory na Ethereu upřednostňovat transakce s vyššími poplatky. @@ -214,40 +214,40 @@ Hlavní řetězec Etherea klade limity na množství dat, která mohou být v bl Optimistické rollupy používají k dosažení komprese dat transakcí a zlepšení rychlosti TPS (transakcí za sekundu) několik technik. Například tento [článek](https://vitalik.eth.limo/general/2021/01/05/rollup.html) porovnává data generovaná základní uživatelskou transakcí (posílání etheru) na Mainnetu a množství dat, která generuje stejná transakce na rollupu: -| Parametr | Ethereum (L1) | Rollup (L2) | -| ----------------------- | --------------------- | ------------- | -| Jedinečné číslo (nonce) | ~3 | 0 | -| Cena paliva | ~8 | 0–0,5 | -| Palivo | 3 | 0–0,5 | -| Pro | 21 | 4 | -| Hodnota | 9 | ~3 | -| Podpis | ~68 (2 + 33 + 33) | ~0,5 | -| Od | 0 (získáno z podpisu) | 4 | -| **Celkem** | **~112 bajtů** | **~12 bajtů** | +| Parametr | Ethereum (L1) | Rollup (L2) | +| ------------------------------------------ | ---------------------------------------------------- | ------------------------------ | +| Jedinečné číslo (nonce) | ~3 | 0 | +| Cena paliva | ~8 | 0–0,5 | +| Palivo | 3 | 0–0,5 | +| Pro | 21 | 4 | +| Hodnota | 9 | ~3 | +| Podpis | ~68 (2 + 33 + 33) | ~0,5 | +| Od | 0 (získáno z podpisu) | 4 | +| **Celkem** | **~112 bajtů** | **~12 bajtů** | Provádění hrubých výpočtů na těchto číslech může ukázat, jaké zlepšení škálovatelnosti optimistické rollupy poskytují: 1. Cílová velikost pro každý blok je 15 milionů jednotek paliva a ověřit jeden bajt dat stojí 16 jednotek paliva. Vydělení průměrné velikosti bloku 16 jednotkami paliva (15 000 000/16) ukazuje, že průměrný blok může obsahovat **937 500 bajtů dat**. 2. Pokud základní transakce rollupu spotřebuje 12 bajtů, pak průměrný blok Etherea může zpracovat **78 125 transakcí rollupu** (937 500/12) nebo **39 balíčků rollupu** (pokud každý balíček obsahuje průměrně 2 000 transakcí). -3. Pokud je nový blok na Ethereu produkován každých 15 sekund, pak by rychlost zpracování rollupu činila přibližně **5 208 transakcí za sekundu**. To se vypočítá tak, že se počet základních transakcí rollupu, které může blok Etherea obsahovat (**78 125)**, vydělí průměrnou dobou bloku (**15 sekund**). +3. Pokud je na Ethereu produkován nový blok každých 15 sekund, pak by rychlost zpracování rollupu činila přibližně **5 208 transakcí za sekundu**. To se vypočítá tak, že se počet základních transakcí rollupu, které může blok Etherea obsahovat (**78 125**), vydělí průměrnou dobou bloku (**15 sekund**). Toto je poměrně optimistický odhad, protože transakce optimistického rollupu nemohou tvořit celý blok na Ethereu. Nicméně to může poskytnout hrubou představu o tom, jaké výhody v oblasti škálovatelnosti mohou optimistické rollupy uživatelům Etherea nabídnout (aktuální implementace nabízejí až 2 000 TPS). -Zavedení [datového shardingu](/roadmap/danksharding/) na Ethereu by mělo zlepšit škálovatelnost optimistických rollupů. Protože transakce rollupu musí sdílet prostor bloku s ostatními netransakcemi rollupu, jejich zpracovatelská kapacita je omezena propustností dat na hlavním řetězci Etherea. Danksharding zvýší prostor dostupný pro L2 řetězce k publikaci dat na blok, využívající levnější, dočasné „blobové“ úložiště místo drahého, trvalého `CALLDATA`. +Zavedení [datového shardingu](/roadmap/danksharding/) na Ethereu by mělo zlepšit škálovatelnost optimistických rollupů. Protože transakce rollupu musí sdílet prostor bloku s ostatními netransakcemi rollupu, jejich zpracovatelská kapacita je omezena propustností dat na hlavním řetězci Etherea. Danksharding zvýší prostor dostupný pro L2 řetězce k publikaci dat na blok, využívající levnější, dočasné úložiště „blobů“ místo drahého, trvalého `CALLDATA`. ### Výhody a nevýhody optimistických rollupů {#optimistic-rollups-pros-and-cons} -| Plusy | Minusy | -| -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Nabízejí masivní zlepšení škálovatelnosti, aniž by obětovaly bezpečnost nebo důvěryhodnost. | Zpoždění finality transakcí kvůli potenciálním výzvám kvůli podvodům. | -| Data transakcí jsou uložena na vrstvě 1, což zlepšuje transparentnost, bezpečnost, odolnost proti cenzuře a decentralizaci. | Centralizovaní operátoři rollupu (sekvencery) mohou ovlivnit pořadí transakcí. | -| Prokázání podvodu zaručuje důvěryhodnou finalitu a umožňuje poctivým minoritám zabezpečit řetězec. | Pokud neexistují poctivé síťové uzly, může zlovolný operátor ukrást prostředky zveřejněním neplatných bloků a stavu. | -| Výpočet důkazů podvodu je přístupný všem běžným uzlům L2, na rozdíl od důkazů platnosti (používaných v ZK-rollupech), které vyžadují speciální hardware. | Bezpečnostní model se spoléhá na alespoň jeden poctivý uzel, který provádí transakce rollupu a podává důkazy podvodu ke zpochybnění neplatných změn stavu. | -| Rollupy těží z „důvěryhodného života“ (kdokoli může přinutit řetězec, aby pokračoval tím, že vykoná transakce a zveřejní tvrzení). | Uživatelé musí počkat, až uplyne týdenní období pro podání výzvy, než si mohou vybrat prostředky zpět na Ethereum. | -| Optimistické rollupy se v otázce zvýšení bezpečnosti řetězce spoléhají na dobře navržené kryptografické ekonomické pobídky. | Rollupy musí zveřejňovat všechna data transakcí na řetězci, což může zvýšit náklady. | -| Kompatibilita s EVM a Solidity umožňuje vývojářům přenášet smart kontrakty nativní na Ethereu na rollupy nebo používat stávající nástroje k vytváření nových dappek. | | +| Plusy | Minusy | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Nabízejí masivní zlepšení škálovatelnosti, aniž by obětovaly bezpečnost nebo důvěryhodnost. | Zpoždění finality transakcí kvůli potenciálním výzvám kvůli podvodům. | +| Data transakcí jsou uložena na vrstvě 1, což zlepšuje transparentnost, bezpečnost, odolnost proti cenzuře a decentralizaci. | Centralizovaní operátoři rollupu (sekvencery) mohou ovlivnit pořadí transakcí. | +| Prokázání podvodu zaručuje důvěryhodnou finalitu a umožňuje poctivým minoritám zabezpečit řetězec. | Pokud neexistují poctivé síťové uzly, může zlovolný operátor ukrást prostředky zveřejněním neplatných bloků a stavu. | +| Výpočet důkazů podvodu je přístupný všem běžným uzlům L2, na rozdíl od důkazů platnosti (používaných v ZK-rollupech), které vyžadují speciální hardware. | Bezpečnostní model se spoléhá na alespoň jeden poctivý uzel, který provádí transakce rollupu a podává důkazy podvodu ke zpochybnění neplatných změn stavu. | +| Rollupy těží z „důvěryhodného života“ (kdokoli může přinutit řetězec, aby pokračoval tím, že vykoná transakce a zveřejní tvrzení). | Uživatelé musí počkat, až uplyne týdenní období pro podání výzvy, než si mohou vybrat prostředky zpět na Ethereum. | +| Optimistické rollupy se v otázce zvýšení bezpečnosti řetězce spoléhají na dobře navržené kryptografické ekonomické pobídky. | Rollupy musí zveřejňovat všechna data transakcí na řetězci, což může zvýšit náklady. | +| Kompatibilita s EVM a Solidity umožňuje vývojářům přenášet smart kontrakty nativní na Ethereu na rollupy nebo používat stávající nástroje k vytváření nových dappek. | | -### Vizualizace optimistických rollupů {#optimistic-video} +### Vizuální vysvětlení optimistických rollupů {#optimistic-video} Učíte se spíše vizuálně? Podívejte se na video od Finematics, které vysvětluje optimistické rollupy: @@ -257,7 +257,9 @@ Učíte se spíše vizuálně? Podívejte se na video od Finematics, které vysv - [Jak fungují optimistické rollupy (kompletní průvodce)](https://www.alchemy.com/overviews/optimistic-rollups) - [Co je to Blockchain Rollup? Technický úvod](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) -- [Zásadní průvodce pro Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) -- [Jak skutečně funguje rollup od Optimism?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) -- [Hloubkový rozbor OVM](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) -- [Co je to Virtuální stroj Optimistic?](https://www.alchemy.com/overviews/optimistic-virtual-machine) +- [Základní průvodce Arbitrum](https://www.bankless.com/the-essential-guide-to-arbitrum) +- [Praktický průvodce rollupy na Ethereu](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) +- [Stav důkazů podvodu na L2 Etherea](https://web.archive.org/web/20241124154627/https://research.2077.xyz/the-state-of-fraud-proofs-in-ethereum-l2s) +- [Jak skutečně funguje rollup Optimismu?](https://www.paradigm.xyz/2021/01/how-does-optimism-s-rollup-really-work) +- [Hloubkový ponor do OVM](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [Co je Optimistic Virtual Machine?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git a/public/content/translations/cs/developers/docs/scaling/plasma/index.md b/public/content/translations/cs/developers/docs/scaling/plasma/index.md index 2a973f894d9..1e73944799d 100644 --- a/public/content/translations/cs/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/cs/developers/docs/scaling/plasma/index.md @@ -1,32 +1,32 @@ --- -title: Plazmové řetězce -description: Úvod do plazmových řetězců jako škálovacího řešení, které v současnosti využívá komunita Etherea. +title: "Plazmové řetězce" +description: "Úvod do plazmových řetězců jako škálovacího řešení, které v současnosti využívá komunita Etherea." lang: cs incomplete: true sidebarDepth: 3 --- -Plazmový řetězec je samostatný blockchain ukotvený na Ethereum Mainnet, ale provádějící transakce mimo řetězec s vlastním mechanismem pro validaci bloků. Plazmové řetězce jsou někdy označovány jako „dceřiné“ řetězce, což jsou v podstatě menší kopie Ethereum Mainnetu. Plazmové řetězce k arbitráži sporů využívají [důkazy podvodů](/glossary/#fraud-proof) (podobně jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)). +Plazmový řetězec je samostatný blockchain ukotvený na hlavní síti Ethereum, ale provádějící transakce mimo řetězec s vlastním mechanismem pro validaci bloků. Plazmové řetězce jsou někdy označovány jako „dceřiné“ řetězce, což jsou v podstatě menší kopie Ethereum Mainnetu. Plasma řetězce používají [důkazy podvodu](/glossary/#fraud-proof) (jako [optimistické rollupy](/developers/docs/scaling/optimistic-rollups/)) k řešení sporů. Merkle trees umožňují vytvoření nekonečného počtu těchto řetězců, které mohou posloužit k odlehčení šířky pásma mateřských řetězců (včetně Ethereum Mainnetu). Nicméně zatímco tyto řetězce odvozují část své bezpečnosti od Etherea (prostřednictvím důkazů podvodů), jejich bezpečnost a efektivita jsou ovlivněny několika konstrukčními omezeními. ## Předpoklady {#prerequisites} -Pro pochopení tohoto článku byste měli dobře rozumět všem základním tématům a skvěle chápat [škálování Etherea](/developers/docs/scaling/). +Měli byste dobře rozumět všem základním tématům a mít obecný přehled o [škálování Etherea](/developers/docs/scaling/). ## Co je Plasma? -Plasma je vývojová platforma pro zlepšení škálovatelnosti na veřejných blockchainech, jako je Ethereum. Jak je popsáno v původním [whitepaperu Plasmy](http://plasma.io/plasma.pdf), plazmové řetězce jsou postaveny na jiném blockchainu (nazývaném „kořenový řetězec“). Každý „dceřiný řetězec“ se rozšiřuje z kořenového řetězce a je obecně spravován smart kontraktem nasazeným na mateřském řetězci. +Plasma je vývojová platforma pro zlepšení škálovatelnosti na veřejných blockchainech, jako je Ethereum. Jak je popsáno v původní [bílé knize Plasma](http://plasma.io/plasma.pdf), jsou plasma řetězce postaveny na jiném blockchainu (nazývaném „kořenový řetězec“). Každý „dceřiný řetězec“ se rozšiřuje z kořenového řetězce a je obecně spravován smart kontraktem nasazeným na mateřském řetězci. -Funkce plazmového kontraktu, mimo jiné, slouží jako [přemostění](/developers/docs/bridges/), které umožňuje uživatelům přesouvat aktiva mezi Ethereum Mainnetem a plazmovým řetězcem. Ačkoliv to je činí podobnými [postranním řetězcům](/developers/docs/scaling/sidechains/), plazmové řetězce těží – alespoň do určité míry – z bezpečnosti Mainnetu Etherea. A tím se od postranním řetězců, které jsou zodpovědné za svou bezpečnost samy, odlišují. +Kontrakt Plasma funguje mimo jiné jako [přemostění](/developers/docs/bridges/), které umožňuje uživatelům přesouvat aktiva mezi hlavní sítí Ethereum a plazmovým řetězcem. Ačkoli je to činí podobnými [sidechainům](/developers/docs/scaling/sidechains/), plazmové řetězce těží – alespoň do určité míry – z bezpečnosti hlavní sítě Ethereum. A tím se od postranním řetězců, které jsou zodpovědné za svou bezpečnost samy, odlišují. ## Jak Plasma funguje? Základními komponentami vývojového rámce Plasma jsou: -### Výpočty mimo blockchain {#off-chain-computation} +### Výpočty mimo řetězec {#offchain-computation} -Současná rychlost zpracování Etherea je omezena na přibližně 15–20 transakcí za sekundu, což snižuje krátkodobou možnost škálování pro obsloužení většího počtu uživatelů. Tento problém existuje hlavně proto, že [konsensuální mechanismus](/developers/docs/consensus-mechanisms/) Etherea vyžaduje, aby spousta peer-to-peer uzlů ověřila každou aktualizaci stavu blockchainu. +Současná rychlost zpracování Etherea je omezena na přibližně 15–20 transakcí za sekundu, což snižuje krátkodobou možnost škálování pro obsloužení většího počtu uživatelů. Tento problém existuje hlavně proto, že [mechanismus konsenzu](/developers/docs/consensus-mechanisms/) Etherea vyžaduje, aby mnoho peer-to-peer uzlů ověřilo každou aktualizaci stavu blockchainu. Ačkoli je konsensuální mechanismus Etherea nezbytný pro bezpečnost, nemusí se vztahovat na každý případ použití. Například Alice možná nepotřebuje, aby její denní platby Bobovi za šálek kávy ověřila celá síť Etherea, protože mezi oběma stranami existuje určitá míra důvěry. @@ -36,13 +36,13 @@ Výpočty mimo řetězec jsou nezbytné, protože plazmové řetězce mohou opti ### Závazky stavu {#state-commitments} -I když Plasma provádí transakce mimo řetězec, vypořádány jsou na hlavní výkonné vrstvě Etherea – jinak by plazmové řetězce nemohly těžit z bezpečnostních záruk Etherea. Ale finalizace transakcí mimo řetězec bez znalosti stavu plazmového řetězce by narušila bezpečnostní model a umožnila rozšíření neplatných transakcí. Proto je operátor, subjekt odpovědný za produkci bloků na plazmovém řetězci, povinen pravidelně zveřejňovat „závazky stavu“ na Ethereu. +I když Plasma provádí transakce mimo řetězec, jsou vypořádány na hlavní exekuční vrstvě Etherea – jinak by plazmové řetězce nemohly těžit z bezpečnostních záruk Etherea. Ale finalizace transakcí mimo řetězec bez znalosti stavu plazmového řetězce by narušila bezpečnostní model a umožnila rozšíření neplatných transakcí. Proto je operátor, subjekt odpovědný za produkci bloků na plazmovém řetězci, povinen pravidelně zveřejňovat „závazky stavu“ na Ethereu. [Schéma závazků](https://en.wikipedia.org/wiki/Commitment_scheme) je kryptografická technika pro zavázání se k hodnotě nebo výroku, aniž by tato hodnota nebo výrok byly odhaleny jiné straně. Závazky jsou „závazné“ v tom smyslu, že nemůžete změnit hodnotu nebo tvrzení, jakmile jste se k němu zavázali. Závazky stavu v Plasmě mají podobu „Merkle kořenů“ (odvozených od [Merkle tree](/whitepaper/#merkle-trees)), které operátor v pravidelných intervalech zasílá do plazmového kontraktu na Ethereu. -Kořeny Merkle jsou kryptografické prvky, které umožňují kompresi velkého množství informací. Merkle kořen (v tomto případě také nazývaný „kořen bloku“) může reprezentovat všechny transakce v bloku. Merkle kořeny také usnadňují ověření, že malý kousek dat je součástí většího datového souboru. Například uživatel může předložit [Merkle důkaz](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) k prokázání zahrnutí transakce do konkrétního bloku. +Kořeny Merkle jsou kryptografické prvky, které umožňují kompresi velkého množství informací. Merkle kořen (v tomto případě také nazývaný „kořen bloku“) může reprezentovat všechny transakce v bloku. Merkle kořeny také usnadňují ověření, že malý kousek dat je součástí většího datového souboru. Uživatel může například vytvořit [Merkleův důkaz](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content) pro prokázání zahrnutí transakce do konkrétního bloku. -Merkle kořeny jsou důležité pro poskytování informací o stavu mimo řetězec Ethereu. Merkle kořeny si můžete představit jako „ukládací body“ – operátor říká: „Toto je stav plazmového řetězce v bodě času x a toto je Merkle kořen jako důkaz.“ Operátor se zavazuje k _aktuálnímu stavu_ plazmového řetězce pomocí Merkle kořene, což je důvod, proč se tomu říká „závazek stavu“. +Merkle kořeny jsou důležité pro poskytování informací o stavu mimo řetězec Ethereu. Merkle kořeny si můžete představit jako „ukládací body“ – operátor říká: „Toto je stav plazmového řetězce v bodě času x a toto je Merkle kořen jako důkaz.“ Operátor se zavazuje k aktuálnímu stavu plazmového řetězce pomocí Merkle kořene, což je důvod, proč se tomu říká „závazek stavu“. ### Vstupy a výstupy {#entries-and-exits} @@ -50,11 +50,11 @@ Aby uživatelé Etherea mohli využívat výhody Plasmy, musí existovat mechani Plasma využívá hlavní kontrakt běžící na Ethereu ke zpracování vstupů a výstupů uživatelů. Tento hlavní kontrakt je také odpovědný za sledování závazků stavu (vysvětleno dříve) a za trestání nepoctivého chování pomocí důkazů podvodů (více o tom později). -#### Vstup do plazmového řetězce {#entering-the-plasma-chain} +#### Vstup na plazmový řetězec {#entering-the-plasma-chain} Aby Alice (uživatel) mohla vstoupit do plazmového řetězce, musí vložit ETH nebo jakýkoli ERC-20 token do plazmového kontraktu. Operátor plazmy, který sleduje vklady do kontraktu, znovu vytvoří částku rovnající se původnímu vkladu Alice a pošle ji na její adresu na plazmovém řetězci. Alice musí potvrdit přijetí prostředků na dceřiném řetězci a poté může tyto prostředky použít pro transakce. -#### Výstup z plazmového řetězce {#exiting-the-plasma-chain} +#### Opuštění plazmového řetězce {#exiting-the-plasma-chain} Výstup z plazmového řetězce je složitější než vstup, a to hned z několika důvodů. Největším je, že zatímco Ethereum má informace o stavu plazmového řetězce, nemůže ověřit, zda jsou tyto informace pravdivé. Podvodník by mohl učinit nesprávné tvrzení („mám 1 000 ETH“) a utéct bez postihu, kdyby poskytl falešné důkazy na podporu tohoto tvrzení. @@ -62,15 +62,15 @@ Aby se předešlo podvodným výběrům, zavádí se „období výzvy“. Běhe Obvykle jsou však uživatelé poctiví a o prostředcích, které vlastní, mluví pravdu. V tomto scénáři Alice zahájí žádost o výběr na kořenovém řetězci (Ethereum) odesláním transakce do plazmového kontraktu. -Alice musí také poskytnout Merkle důkaz ověřující, že transakce, která vytvořila její prostředky na plazmovém řetězci, byla zahrnuta do bloku. To je nezbytné pro varianty Plasmy, jako je [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), které používají model [Unspent Transaction Output (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). +Alice musí také poskytnout Merkle důkaz ověřující, že transakce, která vytvořila její prostředky na plazmovém řetězci, byla zahrnuta do bloku. To je nezbytné pro iterace Plasma, jako je [Plasma MVP](https://www.learnplasma.org/en/learn/mvp.html), které používají model [Unspent Transaction Output (UTXO)](https://en.wikipedia.org/wiki/Unspent_transaction_output). -Jiné varianty, jako je [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), představují prostředky, jako jsou [nezaměnitelné tokeny](/developers/docs/standards/tokens/erc-721/) místo UTXO. V tomto případě je pro výběr nutné předložit důkaz o vlastnictví tokenů na plazmovém řetězci. Toho je možné docílit předložením dvou nejnovějších transakcí zahrnujících token a poskytnutím Merkle důkazu ověřujícího zahrnutí těchto transakcí do bloku. +Jiné, jako [Plasma Cash](https://www.learnplasma.org/en/learn/cash.html), představují prostředky jako [nezaměnitelné tokeny](/developers/docs/standards/tokens/erc-721/) místo UTXO. V tomto případě je pro výběr nutné předložit důkaz o vlastnictví tokenů na plazmovém řetězci. Toho je možné docílit předložením dvou nejnovějších transakcí zahrnujících token a poskytnutím Merkle důkazu ověřujícího zahrnutí těchto transakcí do bloku. Uživatel musí také přidat k žádosti o výběr zástavu jako záruku poctivého chování. Pokud vyzyvatel prokáže neplatnost žádosti o výběr Alice, její záloha je penalizována a část z ní jde vyzyvateli jako odměna. Pokud uplyne období výzvy, aniž by kdokoli poskytl důkaz podvodu, žádost Alice o výběr je považována za platnou, což jí umožňuje vybrat vklady z plazmového kontraktu na Ethereu. -### Arbitráž sporů {#dispute-arbitration} +### Řešení sporů {#dispute-arbitration} Stejně jako u jakéhokoli jiného blockchainu, plazmové řetězce potřebují mechanismus pro vynucení integrity transakcí v případě, že se účastníci chovají podvodně (např. dvojité utrácení prostředků). Za tímto účelem plazmové řetězce používají důkazy podvodů k arbitráži sporů týkajících se platnosti přechodů stavu a k trestání podvodného chování. Důkazy podvodů jsou použity jako mechanismus, kterým plazmový dceřiný řetězec podává stížnost svému mateřskému řetězci nebo kořenovému řetězci. @@ -80,17 +80,17 @@ Aby zabránil výběru, Bob sestaví důkaz podvodu poskytnutím důkazu o tom, Pokud je Bobova výzva úspěšná, žádost Alice o výběr je zrušena. Tento přístup však spoléhá na Bobovu schopnost sledovat řetězec. Pokud je Bob offline, může Alice zpracovat zlovolný výběr, jakmile uplyne období výzvy. -## Problém hromadného výběru z plazmového řetězce {#the-mass-exit-problem-in-plasma} +## Problém hromadného odchodu v Plasma {#the-mass-exit-problem-in-plasma} Problém hromadného výběru nastává, když se velký počet uživatelů naráz pokusí vybrat prostředky z plazmového řetězce. Tento problém existuje kvůli jednomu z největších problémů Plasmy: **nedostupnosti dat**. Dostupnost dat je schopnost ověřit, že informace pro navrhovaný blok byly skutečně zveřejněny na blockchainové síti. Blok je „nedostupný“, pokud producent zveřejní samotný blok, ale zadrží data použitá k vytvoření bloku. -Bloky musí být dostupné, pokud mají být síťové uzly schopny stáhnout blok a ověřit platnost transakcí. Blockchainy zajišťují dostupnost dat tím, že nutí producenty bloků zveřejnit všechna data transakcí na řetězci. +Bloky musí být dostupné, pokud mají být síťové uzly schopny stáhnout blok a ověřit platnost transakcí. Blockchainy zajišťují dostupnost dat tím, že nutí producenty bloků zveřejnit všechna data transakcí na blockchainu. Dostupnost dat také pomáhá zabezpečit škálovací protokoly mimo řetězec, které staví na základní vrstvě Etherea. Tím, že nutí operátory na těchto řetězcích zveřejnit data transakcí na Ethereu, může kdokoli zpochybnit neplatné bloky sestavením důkazů podvodu odkazujících na správný stav řetězce. -Plazmové řetězce primárně ukládají data o transakcích u operátora a **nezveřejňují žádná data na Mainnetu** (tj. kromě pravidelných závazků stavu). To znamená, že uživatelé se musí spoléhat na to, že operátor poskytne data bloků, pokud potřebují vytvořit důkazy podvodu a zpochybnit neplatné transakce. Pokud tento systém funguje, mohou uživatelé vždy využít důkazů podvodu k ochraně svých prostředků. +Plazmové řetězce primárně ukládají data o transakcích u operátora a **nezveřejňují žádná data na hlavní síti** (tj. kromě pravidelných závazků stavu). To znamená, že uživatelé se musí spoléhat na to, že operátor poskytne data bloků, pokud potřebují vytvořit důkazy podvodu a zpochybnit neplatné transakce. Pokud tento systém funguje, mohou uživatelé vždy využít důkazů podvodu k ochraně svých prostředků. Problém nastává, když podvodníkem není běžný uživatel, ale přímo operátor. Protože operátor má plnou kontrolu nad blockchainem, má větší motivaci prosazovat neplatné změny stavu ve větším měřítku, například krást prostředky uživatelů na plazmovém řetězci. @@ -98,41 +98,41 @@ V tomto případě klasický systém důkazů podvodu nefunguje. Operátor by mo Nejoptimističtějším řešením v této situaci je pokus o „hromadný výběr“ uživatelů z plazmového řetězce. Hromadný výběr zpomalí podvodný plán operátora na krádež prostředků a poskytne uživatelům určitou míru ochrany. Žádosti o výběr jsou seřazeny podle toho, kdy bylo vytvořeno každé UTXO (nebo token), čímž se zabrání tomu, aby podvodní operátoři předběhli poctivé uživatele. -Nicméně stále potřebujeme způsob, jak ověřit platnost žádostí o výběr během hromadného výběru, aby se zabránilo tomu, že by oportunističtí jednotlivci využili chaosu a neplatně vybrali prostředky. Řešení je jednoduché: vyžadovat, aby uživatelé jako podmínku výběru svých peněz předložili poslední **platný stav řetězce**. +Nicméně stále potřebujeme způsob, jak ověřit platnost žádostí o výběr během hromadného výběru, aby se zabránilo tomu, že by oportunističtí jednotlivci využili chaosu a neplatně vybrali prostředky. Řešení je jednoduché: vyžadovat od uživatelů, aby pro výběr svých peněz zveřejnili poslední **platný stav řetězce**. Tento přístup má však stále své mouchy. Například pokud všichni uživatelé na plazmovém řetězci potřebují provést výběr (což je možné v případě podvodného operátora), pak musí být celý platný stav plazmového řetězce naráz přenesen na základní vrstvu Etherea. Vzhledem k arbitrární velikosti plazmových řetězců (vyšší propustnost = více dat) a omezením rychlosti zpracování Ethereem to není ideální řešení. Ačkoli výstupní strategie zní teoreticky dobře, skutečné hromadné výběry pravděpodobně vyvolají přetížení sítě na samotném Ethereu. Kromě poškození funkčnosti Etherea může špatně koordinovaný hromadný výběr znamenat, že uživatelé nebudou schopni vybrat své prostředky dříve, než operátor odčerpá prostředky ze všech účtů na plazmovém řetězci. -## Výhody a nevýhody plazmových řetězců {#pros-and-cons-of-plasma} +## Výhody a nevýhody Plasma {#pros-and-cons-of-plasma} -| Plusy | Mínusy | -| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Nabízí vysokou propustnost a nízké náklady na transakci. | Nepodporuje obecné výpočty (nemůže spouštět smart kontrakty. Podporuje pouze základní tokenové transakce, směnu a několik dalších typů transakcí prostřednictvím predikátové logiky. | -| Vhodné pro transakce mezi libovolnými uživateli (bez režie páru uživatelů, pokud jsou oba etablováni na plazmovém řetězci) | Nutnost pravidelně sledovat síť (je třeba být připojen) nebo tuto odpovědnost delegovat na někoho jiného, aby byla zajištěna bezpečnost vašich prostředků. | -| Plazmové řetězce lze přizpůsobit specifickým případům použití, které nesouvisejí s hlavním řetězcem. Každý, včetně firem, si může plazmové smart kontrakty přizpůsobit a poskytnout škálovatelnou infrastrukturu, která funguje v různých kontextech. | Spoléhá na jednoho nebo více operátorů, aby uchovávali data a na požádání je poskytovali. | -| Snižuje zatížení Ethereum Mainnetu přesunem výpočtů a úložiště mimo řetězec. | Výběry jsou zpožděny o několik dní, aby bylo možné podávat výzvy. U zaměnitelných aktiv to mohou zmírnit poskytovatelé likvidity, ale s tím jsou spojeny kapitálové náklady. | -| | Pokud se příliš mnoho uživatelů pokusí o výběr současně, může se Ethereum Mainnet přetížit. | +| Plusy | Minusy | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Nabízí vysokou propustnost a nízké náklady na transakci. | Nepodporuje obecné výpočty (nemůže spouštět smart kontrakty). Podporuje pouze základní tokenové transakce, směnu a několik dalších typů transakcí prostřednictvím predikátové logiky. | +| Vhodné pro transakce mezi libovolnými uživateli (bez režie páru uživatelů, pokud jsou oba etablováni na plazmovém řetězci) | Nutnost pravidelně sledovat síť (je třeba být připojen) nebo tuto odpovědnost delegovat na někoho jiného, aby byla zajištěna bezpečnost vašich prostředků. | +| Plazmové řetězce lze přizpůsobit specifickým případům použití, které nesouvisejí s hlavním řetězcem. Každý, včetně firem, si může plazmové smart kontrakty přizpůsobit a poskytnout škálovatelnou infrastrukturu, která funguje v různých kontextech. | Spoléhá na jednoho nebo více operátorů, aby uchovávali data a na požádání je poskytovali. | +| Snižuje zatížení hlavní sítě Ethereum přesunem výpočtů a úložiště mimo řetězec. | Výběry jsou zpožděny o několik dní, aby bylo možné podávat výzvy. U zaměnitelných aktiv to mohou zmírnit poskytovatelé likvidity, ale s tím jsou spojeny kapitálové náklady. | +| | Pokud se příliš mnoho uživatelů pokusí o výběr současně, může se Ethereum Mainnet přetížit. | ## Plasma versus škálovací protokoly druhé vrstvy {#plasma-vs-layer-2} -Ačkoli byla Plasma kdysi považována za užitečné škálovací řešení pro Ethereum, od tohoto názoru bylo časem upuštěno ve prospěch [škálovacích protokolů druhé vrstvy (L2)](/layer-2/). Řešení škálování na druhé vrstvě napravují několik problémů Plasmy: +Ačkoli byla Plasma kdysi považována za užitečné škálovací řešení pro Ethereum, od tohoto názoru bylo časem upuštěno ve prospěch škálovacích protokolů druhé vrstvy (L2). Řešení škálování na druhé vrstvě napravují několik problémů Plasmy: ### Efektivita {#efficiency} -[Zero-Knowledge rollupy](/developers/docs/scaling/zk-rollups) generují kryptografické důkazy o platnosti každého balíčku transakcí zpracovaných mimo řetězec. To brání uživatelům (a operátorům) v prosazování neplatných změn stavu, čímž se eliminuje potřeba výzev a výstupních strategií. Také to znamená, že uživatelé nemusí pravidelně sledovat řetězec, aby zabezpečili své prostředky. +[Rollupy s nulovou znalostí](/developers/docs/scaling/zk-rollups) generují kryptografické důkazy o platnosti každé dávky transakcí zpracovaných mimo řetězec. To brání uživatelům (a operátorům) v prosazování neplatných změn stavu, čímž se eliminuje potřeba výzev a výstupních strategií. Také to znamená, že uživatelé nemusí pravidelně sledovat řetězec, aby zabezpečili své prostředky. -### Podpora smart kontraktů {#support-for-smart-contracts} +### Podpora pro chytré kontrakty {#support-for-smart-contracts} -Dalším problémem vývojové platformy Plasma byla [neschopnost podporovat exekuci smart kontraktů Etherea](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). V důsledku toho byla většina implementací Plasmy vytvořena především pro jednoduché platby nebo směnu tokenů ERC-20. +Dalším problémem plasma frameworku byla [neschopnost podporovat provádění chytrých kontraktů Etherea](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). V důsledku toho byla většina implementací Plasmy vytvořena především pro jednoduché platby nebo směnu tokenů ERC-20. -Naopak optimistické rollupy jsou kompatibilní s [Virtuálním strojem Etherea](/developers/docs/evm/) a mohou spouštět [smart kontrakty](/developers/docs/smart-contracts/) nativní pro Ethereum, což z nich činí užitečné a _bezpečné_ řešení pro škálování [decentralizovaných aplikací](/developers/docs/dapps/). Podobně se [připravují plány na vytvoření zero-knowledge implementace EVM (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549), která by umožnila ZK-rollupům zpracovávat libovolnou logiku a exekuovat smart kontrakty. +Naopak, optimistické rollupy jsou kompatibilní s [Ethereum Virtual Machine (EVM)](/developers/docs/evm/) a mohou spouštět nativní [chytré kontrakty](/developers/docs/smart-contracts/) Etherea, což z nich dělá užitečné a _bezpečné_ řešení pro škálování [decentralizovaných aplikací](/developers/docs/dapps/). Podobně se připravují plány na [vytvoření implementace EVM s nulovou znalostí (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549), která by umožnila ZK-rollupům zpracovávat libovolnou logiku a provádět chytré kontrakty. ### Nedostupnost dat {#data-unavailability} Jak bylo vysvětleno dříve, Plasma trpí problémem nedostupnosti dat. Pokud by zlovolný operátor prosadil neplatnou změnu na plazmovém řetězci, uživatelé by ji nemohli zpochybnit, protože operátor může zadržet data potřebná k vytvoření důkazu podvodu. Rollupy tento problém řeší tím, že nutí operátory zveřejnit data transakcí na Ethereu, což umožňuje komukoli ověřit stav řetězce a v případě potřeby vytvořit důkazy podvodu. -### Problém hromadného výběru {#mass-exit-problem} +### Problém hromadného odchodu {#mass-exit-problem} ZK-rollupy i optimistické rollupy řeší problém hromadného výběru v Plasmě různými způsoby. Například ZK-rollup spoléhá na kryptografické mechanismy, které zajišťují, že operátoři nemohou za žádných okolností ukrást prostředky uživatelů. @@ -142,13 +142,14 @@ Podobně optimistické rollupy zavádějí období zpoždění u výběrů, běh Plasma, postranní řetězce a sharding jsou si poměrně podobné, protože se všechny nějakým způsobem připojují k Ethereum Mainnetu. Úroveň a síla těchto propojení se však liší, což ovlivňuje bezpečnostní vlastnosti každého škálovacího řešení. -### Plasma vs postranní řetězce {#plasma-vs-sidechains} +### Plasma vs. sidechainy {#plasma-vs-sidechains} -[Postranní řetězec](/developers/docs/scaling/sidechains/) je nezávisle provozovaný blockchain připojený k Ethereum Mainnetu prostřednictvím obousměrného přemostění. [Přemostění](/bridges/) umožňují uživatelům směňovat tokeny mezi oběma blockchainy, aby mohli transakce provádět na postranním řetězci, což snižuje přetížení Ethereum Mainnetu a zlepšuje škálovatelnost. Postranní řetězce používají samostatný konsensuální mechanismus a jsou obvykle mnohem menší než Ethereum Mainnet. V důsledku toho je přesun aktiv na tyto řetězce spojen s vyšším rizikem; vzhledem k nedostatku bezpečnostních záruk, které se dědí z Ethereum Mainnetu v modelu postranního řetězce, hrozí uživatelům při útoku na postranní řetězec ztráta prostředků. +[Sidechain](/developers/docs/scaling/sidechains/) je nezávisle provozovaný blockchain připojený k hlavní síti Ethereum prostřednictvím obousměrného přemostění. [Přemostění](/bridges/) umožňují uživatelům směňovat tokeny mezi oběma blockchainy, aby mohli provádět transakce na sidechainu, což snižuje přetížení hlavní sítě Ethereum a zlepšuje škálovatelnost. +Postranní řetězce používají samostatný konsensuální mechanismus a jsou obvykle mnohem menší než Ethereum Mainnet. V důsledku toho je přesun aktiv na tyto řetězce spojen s vyšším rizikem; vzhledem k nedostatku bezpečnostních záruk, které se dědí z Ethereum Mainnetu v modelu postranního řetězce, hrozí uživatelům při útoku na postranní řetězec ztráta prostředků. Naopak plazmové řetězce odvozují svou bezpečnost od Mainnetu. To je činí měřitelně bezpečnějšími než postranní řetězce. Oba typy řetězců mohou mít různé konsensuální protokoly, ale rozdíl je v tom, že plazmové řetězce zveřejňují Merkle kořeny pro každý blok na Ethereum Mainnetu. Kořeny bloků jsou malé části informací, které můžeme použít k ověření informací o transakcích, které se odehrávají na plazmovém řetězci. Pokud dojde k útoku na plazmový řetězec, uživatelé mohou bezpečně vybrat své prostředky zpět na Mainnet pomocí příslušných důkazů. -### Plasma versus sharding {#plasma-vs-sharding} +### Plasma vs. tříštění {#plasma-vs-sharding} Jak plazmové řetězce, tak i shardovací řetězce pravidelně zveřejňují kryptografické důkazy na Ethereum Mainnet. Oba však mají různé bezpečnostní vlastnosti. @@ -156,20 +157,20 @@ Shardovací řetězce odesílají na Mainnet „srovnávací hlavičky“, kter Plasma se liší v tom, že Mainnet přijímá pouze minimální informace o stavu dceřiných řetězců. To znamená, že Mainnet nemůže účinně ověřovat transakce provedené na dceřiných řetězcích, což je činí méně bezpečnými. -**Je třeba poznamenat**, že sharding blockchainu Ethereum již není v plánu vylepšení. Byl nahrazen škálováním prostřednictvím rollupů a [Dankshardingu](/roadmap/danksharding). +**Poznámka**: Tříštění blockchainu Ethereum již není v plánu. Bylo nahrazeno škálováním pomocí rollupů a [Dankshardingu](/roadmap/danksharding). -### Použití Plasmy {#use-plasma} +### Použití Plasma {#use-plasma} Několik projektů poskytuje implementace Plasmy, které můžete integrovat do svých dappek: - [Polygon](https://polygon.technology/) (dříve Matic Network) -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Učte se o Plasmě](https://www.learnplasma.org/en/) -- [Rychlá připomínka toho, co znamená „sdílená bezpečnost“ a proč je tak důležitá](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) -- [Postranní řetězce vs Plasma vs Sharding](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) -- [Pochopení Plasmy, část 1: Základy](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) -- [Život a smrt Plasmy](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) +- [Zjistěte více o Plasma](https://www.learnplasma.org/en/) +- [Rychlé připomenutí, co znamená „sdílená bezpečnost“ a proč je tak důležitá](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [Sidechainy vs. Plasma vs. tříštění](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [Pochopení Plasma, část 1: Základy](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [Život a smrt Plasma](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) -_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/scaling/sidechains/index.md b/public/content/translations/cs/developers/docs/scaling/sidechains/index.md index 40a3d548d89..20e14001380 100644 --- a/public/content/translations/cs/developers/docs/scaling/sidechains/index.md +++ b/public/content/translations/cs/developers/docs/scaling/sidechains/index.md @@ -1,62 +1,62 @@ --- -title: Sidechains -description: Úvod do postranních řetězců jako škálovacího řešení, které v současnosti využívá komunita Etherea. +title: "Postranní řetězce" +description: "Úvod do postranních řetězců jako škálovacího řešení, které v současnosti využívá komunita Etherea." lang: cs sidebarDepth: 3 --- -Postranní řetězec je samostatný blockchain, který běží nezávisle na Ethereu a je spojen s Ethereum Mainnetem pomocí obousměrného přemostění. Postranní řetězce mohou mít odlišné parametry bloků a [konsensuální algoritmy](/developers/docs/consensus-mechanisms/), které jsou často navrženy pro efektivní zpracování transakcí. Použití postranního řetězce však přináší určité kompromisy, protože nedědí bezpečnostní vlastnosti Etherea. Na rozdíl od [škálovacích řešení na druhé vrstvě](/layer-2/) nezaznamenávají postranní řetězce změny stavu a transakční data zpět na Ethereum Mainnet. +Postranní řetězec je samostatný blockchain, který běží nezávisle na Ethereu a je spojen s Ethereum Mainnetem pomocí obousměrného přemostění. Postranní řetězce mohou mít odlišné parametry bloků a [konsensuální algoritmy](/developers/docs/consensus-mechanisms/), které jsou často navrženy pro efektivní zpracování transakcí. Použití postranního řetězce však přináší určité kompromisy, protože nedědí bezpečnostní vlastnosti Etherea. Na rozdíl od [škálovacích řešení na 2. vrstvě](/layer-2/) postranní řetězce nezaznamenávají změny stavu a transakční data zpět na Ethereum Mainnet. -Postranní řetězce také obětují určitou míru decentralizace nebo bezpečnosti, aby dosáhly vysoké propustnosti ([trilemma škálovatelnosti](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Ethereum se však zavázalo k tomu, že bude škálovat, aniž by ohrozilo decentralizaci a bezpečnost, jak je uvedeno v jeho [vizi](/roadmap/vision/) vylepšení. +Postranní řetězce také obětují určitou míru decentralizace nebo bezpečnosti, aby dosáhly vysoké propustnosti ([trilema škálovatelnosti](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Ethereum se však zavázalo ke škálování bez kompromisů v oblasti decentralizace a bezpečnosti. ## Jak fungují postranní řetězce? {#how-do-sidechains-work} Postranní řetězce jsou nezávislé blockchainy s odlišnou historií, vývojovými plány a designovými úvahami. Zatímco postranní řetězec může sdílet určité povrchové podobnosti s Ethereem, má několik charakteristických vlastností. -### Konsensuální algoritmy {#consensus-algorithms} +### Konsenzuální algoritmy {#consensus-algorithms} Jednou z vlastností, která činí postranní řetězce jedinečnými (tj. odlišnými od Etherea), je použitý konsensuální algoritmus. Postranní řetězce se pro dosažení konsensu nespoléhají na Ethereum a mohou si vybrat alternativní konsensuální protokoly, které vyhovují jejich potřebám. Některé příklady konsensuálních algoritmů používaných na postranních řetězcích zahrnují: -- [Proof of authority](/developers/docs/consensus-mechanisms/poa/) -- [Delegovaný proof-of-stake](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) -- [Byzantine fault tolerance](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained) +- [Důkaz autoritou](/developers/docs/consensus-mechanisms/poa/) +- [Delegovaný důkaz podílem](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [Byzantská odolnost proti chybám](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained). Stejně jako Ethereum mají postranní řetězce validační uzly, které ověřují a zpracovávají transakce, produkují bloky a uchovávají stav blockchainu. Validátoři jsou také zodpovědní za udržování konsensu v celé síti a za její ochranu před škodlivými útoky. -#### Parametry bloků {#block-parameters} +#### Parametry bloku {#block-parameters} -Ethereum stanovuje limity na [dobu blokování](/developers/docs/blocks/#block-time) (tj. dobu potřebnou k vytvoření nových bloků) a [velikost bloků](/developers/docs/blocks/#block-size) (tj. množství dat obsažených v jednom bloku denominovaných v palivu). Naproti tomu postranní řetězce často přijímají odlišné parametry, jako jsou rychlejší doby blokování a vyšší limity paliva, aby dosáhly vysoké propustnosti, rychlých transakcí a nízkých poplatků. +Ethereum stanovuje limity na [doby bloků](/developers/docs/blocks/#block-time) (tj. dobu potřebnou k vytvoření nových bloků) a [velikosti bloků](/developers/docs/blocks/#block-size) (tj. množství dat obsažených v jednom bloku, vyjádřené v palivu). Naproti tomu postranní řetězce často přijímají odlišné parametry, jako jsou rychlejší doby blokování a vyšší limity paliva, aby dosáhly vysoké propustnosti, rychlých transakcí a nízkých poplatků. I když tento přístup určité výhody přináší, má také zásadní důsledky pro decentralizaci a bezpečnost sítě. Parametry bloků, jako jsou rychlé doby blokování a velké velikosti bloků, zvyšují obtížnost provozu úplného síťového uzlu, což ponechává jen několik „superuzlů“ odpovědných za zabezpečení řetězce. V takovém scénáři se zvyšuje riziko tajné dohody validátorů nebo škodlivého převzetí řetězce. -Aby mohly blockchainy škálovat, aniž by utrpěla decentralizace, musí být provoz síťového uzlu otevřený všem, nikoli nutně jen pro strany se specializovaným hardwarem. Proto probíhají snahy zajistit, aby na Ethereu mohl [úplný uzel provozovat](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) kdokoliv. +Aby mohly blockchainy škálovat, aniž by utrpěla decentralizace, musí být provoz síťového uzlu otevřený všem, nikoli nutně jen pro strany se specializovaným hardwarem. Proto probíhají snahy o zajištění toho, aby každý mohl [provozovat plný uzel](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) v síti Ethereum. ### Kompatibilita s EVM {#evm-compatibility} -Některé postranní řetězce jsou kompatibilní s EVM a jsou schopny spouštět kontrakty vyvinuté pro [Virtuální stroj Etherea (EVM)](/developers/docs/evm/). Postranní řetězce kompatibilní s EVM podporují smart kontrakty [napsané v jazyce Solidity](/developers/docs/smart-contracts/languages/), stejně jako jiné jazyky pro smart kontrakty EVM, což znamená, že smart kontrakty napsané pro Ethereum Mainnet budou fungovat i na postranních řetězcích kompatibilních s EVM. +Některé postranní řetězce jsou kompatibilní s EVM a jsou schopny spouštět kontrakty vyvinuté pro [Virtuální stroj Etherea (EVM)](/developers/docs/evm/). Postranní řetězce kompatibilní s EVM podporují chytré kontrakty [napsané v jazyce Solidity](/developers/docs/smart-contracts/languages/), stejně jako jiné jazyky pro chytré kontrakty EVM, což znamená, že chytré kontrakty napsané pro Ethereum Mainnet budou fungovat i na postranních řetězcích kompatibilních s EVM. -To znamená, že pokud chcete použít svou [dappku](/developers/docs/dapps/) na postranním řetězci, stačí nasadit svůj [smart kontrakt](/developers/docs/smart-contracts/) na tento postranní řetězec. Vypadá a funguje stejně jako na Mainnetu – píšete kontrakty v Solidity a interagujete s řetězcem prostřednictvím RPC postranního řetězce. +To znamená, že pokud chcete použít svou [dapp](/developers/docs/dapps/) na postranním řetězci, stačí nasadit svůj [chytrý kontrakt](/developers/docs/smart-contracts/) na tento postranní řetězec. Vypadá a funguje stejně jako na Mainnetu – píšete kontrakty v Solidity a interagujete s řetězcem prostřednictvím RPC postranního řetězce. -Protože jsou postranní řetězce kompatibilní s EVM, jsou považovány za užitečné [škálovací řešení](/developers/docs/scaling/) pro dappky nativní na Ethereu. S vaší dappkou na postranním řetězci mohou uživatelé využívat nižší poplatky za palivo a rychlejší transakce, zejména pokud je Mainnet přetížený. +Protože jsou postranní řetězce kompatibilní s EVM, jsou považovány za užitečné [škválovací řešení](/developers/docs/scaling/) pro dapps nativní na Ethereu. S vaší dappkou na postranním řetězci mohou uživatelé využívat nižší poplatky za palivo a rychlejší transakce, zejména pokud je Mainnet přetížený. Nicméně jak bylo dříve vysvětleno, používání postranního řetězce zahrnuje významné kompromisy. Každý postranní řetězec je zodpovědný za svou bezpečnost a nedědí bezpečnostní vlastnosti Etherea. To zvyšuje možnost škodlivého chování, které může ovlivnit vaše uživatele nebo ohrozit jejich prostředky. -### Pohyb aktiv {#asset-movement} +### Přesun aktiv {#asset-movement} -Aby se samostatný blockchain mohl stát postranním řetězcem Mainnetu Etherea, musí mít schopnost umožnit převod aktiv z Mainnetu. Této interoperability s Ethereem je dosaženo pomocí blockchainového přemostění. [Přemostění](/bridges/) používají smart kontrakty nasazené na Ethereum Mainnet a postranním řetězci k řízení převodu prostředků mezi nimi. +Aby se samostatný blockchain mohl stát postranním řetězcem Mainnetu Etherea, musí mít schopnost umožnit převod aktiv z Mainnetu. Této interoperability s Ethereem je dosaženo pomocí blockchainového přemostění. [Přemostění](/bridges/) používají chytré kontrakty nasazené na Ethereum Mainnet a na postranním řetězci k řízení převodu prostředků mezi nimi. Zatímco přemostění pomáhají uživatelům přesouvat prostředky mezi Ethereem a postranním řetězcem, aktiva mezi těmito dvěma řetězci nejsou fyzicky přesouvána. Místo toho se k převodu hodnoty mezi řetězci používají mechanismy, které obvykle zahrnují mintování a spalování. Více o tom, [jak fungují přemostění](/developers/docs/bridges/#how-do-bridges-work). -## Klady a zápory postranních řetězců {#pros-and-cons-of-sidechains} +## Výhody a nevýhody postranních řetězců {#pros-and-cons-of-sidechains} -| Plusy | Mínusy | -| ----------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -| Technologie, která stojí za postranními řetězci, je dobře zavedená a těží z rozsáhlého výzkumu a vylepšení designu. | Postranní řetězce obětují určitou míru decentralizace a důvěryhodnosti ve prospěch škálovatelnosti. | -| Postranní řetězce podporují obecné výpočty a nabízejí EVM kompatibilitu (mohou spouštět dappky nativní na Ethereu). | Postranní řetězec používá samostatný konsensuální mechanismus a nemá prospěch z bezpečnostních záruk Etherea. | -| Postranní řetězce používají různé modely konsensu k efektivnímu zpracování transakcí a snížení poplatků za transakce pro uživatele. | Postranní řetězce vyžadují vyšší předpoklady důvěry (např. kvórum škodlivých validátorů postranního řetězce může podvádět). | -| Postranní řetězce kompatibilní s EVM umožňují dappkám rozšířit jejich ekosystém. | | +| Plusy | Minusy | +| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Technologie, která stojí za postranními řetězci, je dobře zavedená a těží z rozsáhlého výzkumu a vylepšení designu. | Postranní řetězce obětují určitou míru decentralizace a důvěryhodnosti ve prospěch škálovatelnosti. | +| Postranní řetězce podporují obecné výpočty a nabízejí EVM kompatibilitu (mohou spouštět dappky nativní na Ethereu). | Postranní řetězec používá samostatný konsensuální mechanismus a nemá prospěch z bezpečnostních záruk Etherea. | +| Postranní řetězce používají různé modely konsensu k efektivnímu zpracování transakcí a snížení poplatků za transakce pro uživatele. | Postranní řetězce vyžadují vyšší předpoklady důvěry (např. kvórum škodlivých validátorů postranního řetězce může podvádět). | +| Postranní řetězce kompatibilní s EVM umožňují dappkám rozšířit jejich ekosystém. | | -### Použití postranních řetězců {#use-sidechains} +### Použijte postranní řetězce {#use-sidechains} Několik projektů poskytuje implementace postranních řetězců, které můžete integrovat do svých dappek: @@ -66,8 +66,8 @@ Několik projektů poskytuje implementace postranních řetězců, které může - [Loom Network](https://loomx.io/) - [Metis Andromeda](https://www.metis.io/) -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Škálování dappek na Ethereu pomocí postranních řetězců](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447)_, 8. února 2018 – Georgios Konstantopoulos_ +- [Škálování dapps na Ethereu pomocí postranních řetězců](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _8. února 2018 - Georgios Konstantopoulos_ _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/scaling/state-channels/index.md b/public/content/translations/cs/developers/docs/scaling/state-channels/index.md index 9b63fd7bdaf..69ce9d16023 100644 --- a/public/content/translations/cs/developers/docs/scaling/state-channels/index.md +++ b/public/content/translations/cs/developers/docs/scaling/state-channels/index.md @@ -1,13 +1,13 @@ --- -title: Stavové kanály -description: Úvod do stavových kanálů a platebních kanálů jako škálovacího řešení, které v současné době využívá komunita Etherea. +title: "Stavové kanály" +description: "Úvod do stavových kanálů a platebních kanálů jako škálovacího řešení, které v současné době využívá komunita Etherea." lang: cs sidebarDepth: 3 --- -Stavové kanály umožňují účastníkům bezpečně transakčně komunikovat mimo řetězec, přičemž minimalizují interakci s Ethereum Mainnetem. Partneři v tomto kanálu mohou provést libovolný počet transakcí mimo řetězec, přičemž na řetězec se zapisují pouze dvě transakce – jedna pro otevření kanálu a druhá pro jeho uzavření. Tím je dosaženo extrémně vysoké propustnosti transakcí a nižších nákladů pro uživatele. +Stavové kanály umožňují účastníkům bezpečně provádět transakce mimo řetězec a zároveň omezují interakci s hlavní sítí Ethereum na minimum. Partneři v tomto kanálu mohou provést libovolný počet transakcí mimo řetězec, přičemž na řetězec se zapisují pouze dvě transakce – jedna pro otevření kanálu a druhá pro jeho uzavření. Tím je dosaženo extrémně vysoké propustnosti transakcí a nižších nákladů pro uživatele. -## Prerequisites {#prerequisites} +## Předpoklady {#prerequisites} Měli byste mít přečteny naše stránky o [škálování Etherea](/developers/docs/scaling/) a [vrstvě 2](/layer-2/). @@ -19,7 +19,7 @@ Kanály jsou jednoduché peer-to-peer protokoly, které umožňují dvěma stran Ve stavových kanálech jsou změny stavu prováděny a ověřovány zainteresovanými stranami, což minimalizuje výpočty na exekuční vrstvě Etherea. To snižuje přetížení na Ethereu a zároveň zvyšuje rychlost zpracování transakcí uživatelů. -Každý kanál je spravován [chytrým kontraktem typu multisig](/developers/docs/smart-contracts/#multisig) běžícím na Ethereu. K otevření kanálu účastníci nasadí kontrakt kanálu na řetězec a vloží do něj prostředky. Obě strany společně podepíší aktualizaci stavu, aby inicializovaly stav kanálu, po čemž mohou rychle a volně transakčně komunikovat mimo řetězec. +Každý kanál je spravován [chytrým kontraktem typu multisig](/developers/docs/smart-contracts/#multisig) běžícím na Ethereu. K otevření kanálu účastníci nasadí kontrakt kanálu na řetězec a vloží do něj prostředky. Obě strany společně podepíší aktualizaci stavu, aby inicializovaly stav kanálu, po čemž mohou rychle a volně provádět transakce mimo řetězec. K uzavření kanálu účastníci předloží na řetězec poslední dohodnutý stav kanálu. Poté chytrý kontrakt rozdělí uzamčené prostředky podle zůstatku každého účastníka v konečném stavu kanálu. @@ -31,19 +31,19 @@ Platební kanál je nejlépe popsán jako „obousměrná účetní kniha“, kt Aktualizace zůstatku účetní knihy (tj. stavu platebního kanálu) vyžaduje souhlas všech stran v kanálu. Aktualizace kanálu, podepsaná všemi účastníky kanálu, je považována za konečnou, podobně jako transakce na Ethereu. -Platební kanály patřily mezi první škálovací řešení navržená k minimalizaci drahých on-chain aktivit nebo jednoduchých uživatelských interakcí (např. převody ETH, atomické směny, převody malých částek). Účastníci kanálu mohou mezi sebou provádět neomezené množství okamžitých, bezpoplatkových transakcí, dokud čistá suma jejich převodů nepřekročí vložené tokeny. +Platební kanály patřily mezi první škálovací řešení navržená k minimalizaci nákladné on-chain aktivity jednoduchých uživatelských interakcí (např. převody ETH, atomické směny, mikroplatby). Účastníci kanálu mohou mezi sebou provádět neomezené množství okamžitých, bezpoplatkových transakcí, dokud čistá suma jejich převodů nepřekročí vložené tokeny. ## Stavové kanály {#state-channels} -Kromě podpory off-chain plateb se platební kanály neukázaly býti užitečnými pro zpracování obecné logiky změny stavu. Stavové kanály byly vytvořeny k vyřešení tohoto problému a ke zpřístupnění kanálů pro škálování obecného výpočtu. +Kromě podpory plateb mimo řetězec (offchain) se platební kanály neosvědčily pro zpracování obecné logiky přechodu stavu. Stavové kanály byly vytvořeny k vyřešení tohoto problému a ke zpřístupnění kanálů pro škálování obecného výpočtu. Stavové kanály mají stále mnoho společného s platebními kanály. Například uživatelé komunikují výměnou kryptograficky podepsaných zpráv (transakcí), které musí podepsat i ostatní účastníci kanálu. Pokud navrhovaná aktualizace stavu není podepsána všemi účastníky, je považována za neplatnou. Nicméně kromě držení zůstatků uživatelů kanál také sleduje aktuální stav úložiště kontraktu (tj. hodnoty proměnných kontraktu). -To umožňuje exekuovat chytrý kontrakt mimo řetězec mezi dvěma uživateli. V tomto scénáři vyžadují aktualizace interního stavu chytrého kontraktu pouze souhlas partnerů, kteří kanál vytvořili. +To umožňuje spustit chytrý kontrakt mimo řetězec mezi dvěma uživateli. V tomto scénáři vyžadují aktualizace interního stavu chytrého kontraktu pouze souhlas partnerů, kteří kanál vytvořili. -I když toto řeší dříve popsaný problém se škálovatelností, má to vliv na bezpečnost. Na Ethereu je platnost přechodů stavu vynucována konsenzuálním protokolem sítě. To znemožňuje navrhnout neplatnou aktualizaci stavu chytrého kontraktu nebo změnit exekuci chytrého kontraktu. +I když toto řeší dříve popsaný problém se škálovatelností, má to vliv na bezpečnost. Na Ethereu je platnost přechodů stavu vynucována konsensuálním protokolem sítě. To znemožňuje navrhnout neplatnou aktualizaci stavu chytrého kontraktu nebo změnit exekuci chytrého kontraktu. Stavové kanály nemají stejné bezpečnostní záruky. Do určité míry je stavový kanál miniaturou Mainnetu. S omezeným počtem účastníků, kteří vynucují pravidla, se zvyšuje možnost podvodů (např. návrhu neplatných aktualizací stavu). Stavové kanály odvozují svoji bezpečnost z arbitrážního systému založeného na [důkazech podvodu](/glossary/#fraud-proof). @@ -55,7 +55,7 @@ Následující část popisuje základní pracovní tok stavového kanálu: ### Otevření kanálu {#opening-the-channel} -Otevření kanálu vyžaduje, aby účastníci vložili prostředky do chytrého kontraktu na Mainnetu. Tento vklad také funguje jako virtuální účet, takže účastníci mohou volně transakčně komunikovat bez potřeby okamžitého vypořádání plateb. Strany si vyrovnají své zůstatky a vyberou zbylé prostředky pouze tehdy, když je kanál uzavřen. +Otevření kanálu vyžaduje, aby účastníci vložili prostředky do chytrého kontraktu na Mainnetu. Tento vklad také funguje jako virtuální účet, takže účastníci mohou volně transakčně komunikovat bez potřeby okamžitého vypořádání plateb. Strany se vzájemně vyrovnají a vyberou si zbytek svých prostředků až poté, co je kanál finalizován na řetězci. Tento vklad také slouží jako záruka čestného chování každého účastníka. Pokud jsou vkladatelé během fáze řešení sporů shledáni vinnými z nekalých praktik, kontrakt jim jejich vklad sníží. @@ -87,7 +87,7 @@ Výše popsaný scénář představuje, co se děje v ideálním případě. Ně - Účastníci odmítnou spolupodepsat platné aktualizace stavu -- Účastníci se pokusí uzavřít kanál tím, že navrhnou starou aktualizaci stavu on-chain kontraktu +- Účastníci se pokusí kanál finalizovat tím, že on-chain kontraktu navrhnou starou aktualizaci stavu. - Účastníci navrhnou neplatné přechody stavu k podepsání ostatním @@ -97,19 +97,19 @@ Kdykoliv dojde k rozpadu konsenzu mezi účastníky kanálu, poslední možnost Obvykle se strany v kanálu předem dohodnou na uzavření kanálu a spolupodepíší poslední přechod stavu, který předloží chytrému kontraktu. Jakmile je aktualizace on-chain schválena, exekuce off-chain chytrého kontraktu končí a účastníci vystoupí z kanálu se svými prostředky. -Nicméně jedna strana může předložit on-chain žádost o ukončení exekuce chytrého kontraktu a uzavření kanálu – aniž by čekala na schválení od druhé strany. Pokud nastane některá z výše popsaných situací narušujících konsenzus, může kterákoli ze stran aktivovat on-chain kontrakt k uzavření kanálu a distribuci finančních prostředků. Tím je zajištěna **nezávislost na důvěře**, což zaručuje, že poctivé strany mohou kdykoliv vybrat své vklady, bez ohledu na akce druhé strany. +Jedna strana však může podat on-chain žádost o ukončení provádění chytrého kontraktu a finalizaci kanálu – aniž by čekala na schválení od protistrany. Pokud nastane některá z výše popsaných situací narušujících konsenzus, může kterákoli ze stran aktivovat on-chain kontrakt k uzavření kanálu a distribuci finančních prostředků. Tím je zajištěna **nezávislost na důvěře**, což zaručuje, že poctivé strany mohou kdykoliv vybrat své vklady, bez ohledu na akce druhé strany. Pro zpracování výstupu z kanálu musí uživatel předložit on-chain kontraktu poslední platnou aktualizaci stavu aplikace. Pokud je tato aktualizace schválena (tj. nese podpis všech stran), prostředky jsou přerozděleny v jejich prospěch. Existuje však zpoždění při provádění žádostí o výstup od jediné strany. Pokud byla žádost o uzavření kanálu jednomyslně schválena, pak je on-chain výstupní transakce provedena okamžitě. -Zpoždění nastává při žádosti o výstup jen od jediné strany a to z důvodu možnosti podvodných akcí. Například účastník kanálu se může pokusit uzavřít kanál na Ethereu předložením starší aktualizace stavu on-chain. +Zpoždění nastává při žádosti o výstup jen od jediné strany a to z důvodu možnosti podvodných akcí. Například účastník kanálu se může pokusit finalizovat kanál na Ethereu předložením starší aktualizace stavu on-chain. Jako protiopatření umožňují stavové kanály poctivým uživatelům napadnout neplatné aktualizace stavu předložením nejnovějšího platného stavu kanálu on-chain. Stavové kanály jsou navrženy tak, že novější, domluvené aktualizace stavu mají přednost před staršími aktualizacemi stavu. Jakmile některá ze stran vyvolá on-chain systém řešení sporů, druhá strana je povinna odpovědět v časovém limitu (tzv. „okno pro výzvy“). To umožňuje uživatelům napadnout výstupní transakci, zejména pokud druhá strana uplatňuje zastaralou aktualizaci. -Ať už je situace jakákoliv, uživatelé kanálu mají vždy silné záruky finálnosti: Pokud je přechod stavu, který mají k dispozici, podepsán všemi členy a je to nejnovější aktualizace, má stejnou finálnost jako běžná on-chain transakce. Stále musí na řetězci vyzvat druhou stranu, ale jediným možným výsledkem je finalizace posledního platného stavu, který drží. +Ať už je situace jakákoliv, uživatelé kanálu mají vždy silné záruky finality: Pokud je přechod stavu, který mají k dispozici, podepsán všemi členy a je to nejnovější aktualizace, má stejnou finalitu jako běžná on-chain transakce. Stále musí na řetězci vyzvat druhou stranu, ale jediným možným výsledkem je finalizace posledního platného stavu, který drží. ### Jak stavové kanály interagují s Ethereem? {#how-do-state-channels-interact-with-ethereum} @@ -131,21 +131,21 @@ V takovém případě poskytuje poctivá strana nejnovější platný stav kaná #### 3. Konečnost {#finality} -Aktualizace stavu kolektivně podepsané uživateli kanálu jsou považovány za stejně dobré jako on-chain transakce. Přesto veškerá aktivita v kanálu dosáhne skutečné finálnosti až tehdy, když je kanál uzavřen na Ethereu. +Aktualizace stavu, které společně podepsali uživatelé kanálu, jsou považovány za rovnocenné on-chain transakcím. Přesto veškerá aktivita v kanálu dosáhne skutečné finálnosti až tehdy, když je kanál uzavřen na Ethereu. V optimistickém případě mohou obě strany spolupracovat, podepsat konečnou aktualizaci stavu a předložit ji on-chain, aby uzavřely kanál, po čemž jsou prostředky rozděleny podle konečného stavu kanálu. V pesimistickém případě, kdy se někdo pokusí podvádět tím, že zveřejní nesprávnou aktualizaci stavu on-chain, jeho transakce nebude finalizována, dokud neuplyne časové okno pro výzvy. ## Virtuální stavové kanály {#virtual-state-channels} -Naivní implementace stavového kanálu by spočívala v nasazení nového kontraktu, když si dva uživatelé přejí spustit aplikaci mimo řetězec. To však není jen nepraktické, ale také to popírá nákladovou efektivitu stavových kanálů (náklady na on-chain transakce se mohou začít rychle stupňovat). +Naivní implementace stavového kanálu by spočívala v nasazení nového kontraktu, když si dva uživatelé přejí spustit aplikaci mimo řetězec. To je nejen neproveditelné, ale také to popírá nákladovou efektivitu stavových kanálů (náklady na on-chain transakce se mohou rychle sčítat). -K vyřešení tohoto problému byly vytvořeny „virtuální kanály“. Na rozdíl od běžných kanálů, které vyžadují on-chain transakce k otevření a uzavření, lze virtuální kanál otevřít, exekuovat a uzavřít bez interakce s hlavním řetězcem. Pomocí této metody je dokonce možné řešit spory mimo řetězec. +K vyřešení tohoto problému byly vytvořeny „virtuální kanály“. Na rozdíl od běžných kanálů, které k otevření a ukončení vyžadují on-chain transakce, lze virtuální kanál otevřít, provést a finalizovat bez interakce s hlavním řetězcem. Pomocí této metody je dokonce možné řešit spory mimo řetězec. Tento systém spoléhá na existenci tzv. „účetních kanálů“, které byly financovány on-chain. Virtuální kanály mezi dvěma stranami mohou být vytvořeny na vrcholu existujícího účetního kanálu, přičemž vlastník (či vlastníci) účetního kanálu slouží jako prostředník. Uživatelé v každém virtuálním kanálu interagují prostřednictvím nové instance kontraktu, přičemž účetní kanál je schopen podporovat více instancí kontraktů. Stav účetního kanálu také obsahuje více než jeden stav úložiště kontraktu, což umožňuje paralelní provádění aplikací mimo řetězec mezi různými uživateli. -Stejně jako u běžných kanálů si uživatelé vyměňují aktualizace stavu za účelem rozvoje stavového stroje. Pokud nedojde ke sporu, prostředník je kontaktován pouze při otevření nebo uzavření kanálu. +Stejně jako u běžných kanálů si uživatelé vyměňují aktualizace stavu za účelem rozvoje stavového stroje. Pokud nedojde ke sporu, prostředník musí být kontaktován pouze při otevírání nebo ukončování kanálu. ### Virtuální platební kanály {#virtual-payment-channels} @@ -159,15 +159,15 @@ První blockchainové kanály byly jednoduché protokoly, které umožňovaly dv Platby založené na kanálech mají následující výhody: -1. **Propustnost**: Množství transakcí mimo řetězec není spojeno s propustností Etherea, kterou ovlivňuje řada faktorů, zejména velikost bloku a doba bloku. Prováděním transakcí mimo řetězec mohou blockchainové kanály dosáhnout vyšší propustnosti. +1. **Propustnost**: Počet transakcí mimo řetězec na kanál nesouvisí s propustností sítě Ethereum, která je ovlivněna různými faktory, zejména velikostí bloku a časem bloku. Prováděním transakcí mimo řetězec mohou blockchainové kanály dosáhnout vyšší propustnosti. -2. **Soukromí**: Protože kanály existují mimo řetězec, podrobnosti o interakcích mezi účastníky nejsou zaznamenány na veřejném blockchainu Etherea. Uživatelé kanálu musí interagovat on-chain pouze při otevírání a uzavírání kanálů nebo řešení sporů. Proto jsou kanály užitečné pro jednotlivce, kteří si přejí více soukromí při provádění transakcí. +2. **Soukromí**: Protože kanály existují mimo řetězec, podrobnosti o interakcích mezi účastníky nejsou zaznamenány na veřejném blockchainu Etherea. Uživatelé kanálu musí interagovat on-chain pouze při financování a uzavírání kanálů nebo řešení sporů. Proto jsou kanály užitečné pro jednotlivce, kteří si přejí více soukromí při provádění transakcí. -3. **Latence**: Transakce mimo řetězec prováděné mezi účastníky kanálu mohou být vypořádány okamžitě, kdy obě strany spolupracují, což snižuje zpoždění. Naproti tomu odeslání transakce na Mainnetu vyžaduje počkat, až síťové uzly zpracují transakci, vytvoří nový blok s transakcí a dosáhnou konsenzu. Uživatelé také mohou chtít čekat na potvrzení dalších bloků, než budou transakci považovat za finální. +3. **Latence**: Transakce mimo řetězec prováděné mezi účastníky kanálu mohou být vypořádány okamžitě, pokud obě strany spolupracují, což snižuje zpoždění. Naproti tomu odeslání transakce na Mainnetu vyžaduje počkat, až síťové uzly zpracují transakci, vytvoří nový blok s transakcí a dosáhnou konsenzu. Uživatelé také mohou chtít čekat na potvrzení dalších bloků, než budou transakci považovat za finální. 4. **Náklady**: Stavové kanály jsou obzvláště užitečné v situacích, kdy si bude skupina účastníků vyměňovat mnoho aktualizací stavu po delší dobu. Jediné náklady, které vzniknou, jsou na otevření a uzavření chytrého kontraktu stavového kanálu; každá změna stavu mezi otevřením a uzavřením kanálu bude levnější než ta předchozí, protože se náklady na vypořádání rozdělí. -Implementace stavových kanálů v řešeních vrstvy 2, jako jsou [rollupy](/developers/docs/scaling/#rollups), by mohla učinit platby ještě atraktivnějšími. Zatímco kanály nabízejí levné platby, náklady na nastavení on-chain kontraktu na Mainnetu během fáze otevření mohou být drahé – zejména když se zvýší palivové poplatky. Rollupy založené na Ethereu nabízejí [nižší transakční poplatky](https://l2fees.info/) a mohou snížit režii pro účastníky kanálů tím, že snižují náklady na jejich nastavení. +Implementace stavových kanálů v řešeních vrstvy 2, jako jsou [rollupy](/developers/docs/scaling/#rollups), by mohla učinit platby ještě atraktivnějšími. Zatímco kanály nabízejí levné platby, náklady na nastavení on-chain kontraktu na Mainnetu během fáze otevření mohou být drahé – zejména když se zvýší poplatky za gas. Rollupy založené na Ethereu nabízejí [nižší transakční poplatky](https://l2fees.info/) a mohou snížit režii pro účastníky kanálů tím, že snižují náklady na jejich nastavení. ### Mikrotransakce {#microtransactions} @@ -181,17 +181,17 @@ Kromě nákladů na otevření a uzavření kanálu účastníkům nevznikají Stejně jako platební kanály mohou stavové kanály dělat podmíněné platby podle konečných stavů stavového stroje. Stavové kanály mohou také podporovat libovolnou logiku přechodu stavu, což je činí užitečnými pro spouštění obecných aplikací mimo řetězec. -Stavové kanály jsou často omezeny na jednoduché tahové aplikace, protože to usnadňuje správu finančních prostředků vázaných na on-chain kontrakt. Také s omezeným počtem stran, které v intervalech aktualizují stav aplikace mimo řetězec, je relativně snadné potrestat podvodníky. +Stavové kanály jsou často omezeny na jednoduché tahové aplikace, protože to usnadňuje správu finančních prostředků vázaných na on-chain kontrakt. S omezeným počtem stran, které v intervalech aktualizují stav aplikace mimo řetězec, je také relativně snadné potrestat nečestné chování. -Efektivita aplikace stavového kanálu také závisí na jejím návrhu. Například vývojář může nasadit kontrakt kanálu aplikace on-chain jen jednou a umožnit ostatním uživatelům znovu používat tuto aplikaci, aniž by museli být on-chain. V tomto případě slouží počáteční kanál aplikace jako účetní kanál podporující více virtuálních kanálů, z nichž každý provozuje novou instanci chytrého kontraktu aplikace mimo řetězec. +Efektivita aplikace stavového kanálu také závisí na jejím návrhu. Například vývojář může nasadit kontrakt kanálu aplikace on-chain jen jednou a umožnit ostatním hráčům znovu používat tuto aplikaci, aniž by museli na řetězec. V tomto případě slouží počáteční kanál aplikace jako účetní kanál podporující více virtuálních kanálů, z nichž každý provozuje novou instanci chytrého kontraktu aplikace mimo řetězec. -Potenciálním příkladem použití stavových kanálů jsou jednoduché hry pro dva hráče, kde jsou prostředky rozděleny na základě výsledku hry. Výhodou je, že hráči si nemusí důvěřovat (nezávislost na důvěře) a on-chain kontrakt, nikoli hráči, kontroluje alokaci prostředků a řešení sporů (decentralizace). +Potenciálním příkladem použití stavových kanálů jsou jednoduché hry pro dva hráče, kde jsou prostředky rozděleny na základě výsledku hry. Výhodou je, že hráči si nemusí důvěřovat (nedůvěryhodnost) a alokaci prostředků a řešení sporů (decentralizace) řídí on-chain kontrakt, nikoli hráči. Další možná využití stavových kanálů zahrnují vlastnictví názvů v ENS, NFT účetní knihy a mnoho dalších. ### Atomické převody {#atomic-transfers} -První platební kanály byly omezeny na převody mezi dvěma stranami, což omezovalo jejich použitelnost. Nicméně zavedení virtuálních kanálů umožnilo jednotlivcům provádět transfery s využitím prostředníků (tj. více p2p kanálů), aniž by museli otevírat nový kanál on-chain. +První platební kanály byly omezeny na převody mezi dvěma stranami, což omezovalo jejich použitelnost. Zavedení virtuálních kanálů však jednotlivcům umožnilo směrovat převody přes prostředníky (tj. více p2p kanálů), aniž by museli otevírat nový kanál on-chain. Běžně popisované jako „multi-hop převody“, směrované platby jsou atomické (tj. buď všechny části transakce uspějí, nebo transakce selže jako celek). Atomické převody využívají [hashované timelock kontrakty (HTLC)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) k zajištění toho, že platba bude uvolněna pouze tehdy, pokud jsou splněny určité podmínky, což snižuje riziko podvodu protistrany. @@ -203,7 +203,7 @@ Aby byla zajištěna efektivita, stavové kanály stanovují časové limity, b Ve skutečnosti mohou uživatelé zůstat offline z důvodů mimo jejich kontrolu (např. špatné internetové připojení, mechanická porucha atd.). Pokud poctivý uživatel zůstane offline, může škodlivý partner situace využít tím, že předloží soudci staré mezistavy kontraktu a tak si přisvojí cizí prostředky. -Některé kanály používají „strážní věže“ – subjekty zodpovědné za sledování on-chain sporů jménem ostatních a za podnikání nezbytných kroků, jako je upozornění zúčastněných stran. To však může zvýšit náklady na používání stavového kanálu. +Některé kanály používají „strážní věže“ (watchtowers) – entity odpovědné za sledování on-chain sporů jménem ostatních a za podnikání nezbytných kroků, jako je upozornění zúčastněných stran. To však může zvýšit náklady na používání stavového kanálu. ### Nedostupnost dat {#data-unavailability} @@ -217,7 +217,7 @@ Uživatelé Etherea se s tímto problémem nemusí potýkat, protože síť vynu Pro založení blockchainového kanálu musí účastníci uzamknout finanční prostředky v on-chain chytrém kontraktu po dobu životního cyklu kanálu. To snižuje likviditu uživatelů kanálu a také omezuje kanály na ty, které si mohou dovolit držet prostředky uzamčené na Mainnetu. -Nicméně účetní kanály – provozované off-chain poskytovatelem služeb (OSP) – mohou snížit problémy s likviditou uživatelů. Dva partneři připojení k účetnímu kanálu mohou vytvořit virtuální kanál, který mohou kdykoli otevřít a uzavřít zcela mimo řetězec. +Problémy s likviditou uživatelů však mohou snížit účetní kanály – provozované off-chain poskytovatelem služeb (OSP). Dva partneři připojení k účetnímu kanálu mohou vytvořit virtuální kanál, který mohou kdykoli otevřít a finalizovat zcela mimo řetězec. Poskytovatelé služeb mimo řetězec by také mohli otevřít kanály s více partnery, což je činí užitečnými pro směrování plateb. Uživatelé samozřejmě musí za služby OSP platit poplatky, což pro některé může být nežádoucí. @@ -225,7 +225,7 @@ Poskytovatelé služeb mimo řetězec by také mohli otevřít kanály s více p Smuteční útoky jsou běžným rysem systémů založených na důkazech podvodu. Takový útok nepřináší přímý prospěch útočníkovi, ale způsobuje „smutek“ (tj. újmu) oběti, což dává název tomuto útoku. -Důkazní systém podvodu je ke smutečním útokům náchylný, protože poctivá strana musí reagovat na každý spor, i neplatný, nebo riskovat ztrátu svých prostředků. Podvodník se může rozhodnout opakovaně zveřejňovat zastaralé přechody stavu on-chain, což nutí poctivou stranu reagovat platným stavem. Náklady na tyto on-chain transakce se mohou rychle nasčítat, což způsobí, že poctivá strana v tomto procesu utrpí ztrátu. +Důkazní systém podvodu je ke smutečním útokům náchylný, protože poctivá strana musí reagovat na každý spor, i neplatný, nebo riskovat ztrátu svých prostředků. Zlomyslný účastník se může rozhodnout opakovaně zveřejňovat zastaralé přechody stavu on-chain, což nutí poctivou stranu reagovat platným stavem. Náklady na tyto on-chain transakce se mohou rychle sčítat, což způsobuje, že poctivé strany v tomto procesu tratí. ### Předdefinované sestavy účastníků {#predefined-participant-sets} @@ -235,7 +235,7 @@ I když to usnadňuje úvahy o stavových kanálech, omezuje to užitečnost ná ### Zpracování paralelních transakcí {#parallel-transaction-processing} -Účastníci stavového kanálu posílají aktualizace stavu postupně, což je důvod, proč nejlépe fungují pro „aplikace založené na střídání tahů“ (např. šachová hra pro dva hráče). To eliminuje potřebu zpracovávat současné aktualizace stavu a snižuje zátěž, kterou on-chain kontrakt musí zvládnout, aby potrestal ty, kteří zveřejňují zastaralé aktualizace. Vedlejším efektem tohoto návrhu však je, že transakce jsou na sobě závislé, což zvyšuje latenci a zhoršuje celkový uživatelský zážitek. +Účastníci stavového kanálu posílají aktualizace stavu postupně, což je důvod, proč nejlépe fungují pro „aplikace založené na střídání tahů“ (např. šachová hra pro dva hráče). To eliminuje potřebu zpracovávat současné aktualizace stavu a snižuje práci, kterou musí on-chain kontrakt vykonat, aby potrestal ty, kteří zveřejňují zastaralé aktualizace. Vedlejším efektem tohoto návrhu však je, že transakce jsou na sobě závislé, což zvyšuje latenci a zhoršuje celkový uživatelský zážitek. Některé stavové kanály řeší tento problém pomocí „full-duplex“ návrhu, který rozděluje off-chain stav na dva jednosměrné „simplexní“ stavy, což umožňuje souběžné aktualizace stavu. Takové návrhy zlepšují propustnost mimo řetězec a snižují zpoždění transakcí. @@ -249,7 +249,7 @@ Několik projektů poskytuje implementace stavových kanálů, které můžete i - [Raiden](https://raiden.network/) - [Statechannels.org](https://statechannels.org/) -## Further reading {#further-reading} +## Další čtení {#further-reading} **Stavové kanály** diff --git a/public/content/translations/cs/developers/docs/scaling/validium/index.md b/public/content/translations/cs/developers/docs/scaling/validium/index.md index 3ca3b9b0325..ee11448177a 100644 --- a/public/content/translations/cs/developers/docs/scaling/validium/index.md +++ b/public/content/translations/cs/developers/docs/scaling/validium/index.md @@ -1,23 +1,23 @@ --- title: Validium -description: Úvod do Validia jako škálovacího řešení, které v současné době využívá komunita Etherea. +description: "Úvod do Validia jako škálovacího řešení, které v současné době využívá komunita Etherea." lang: cs sidebarDepth: 3 --- -Validium je [škálovací řešení](/developers/docs/scaling/), které zajišťuje integritu transakcí pomocí důkazů o platnosti, podobně jako [ZK-rollupy](/developers/docs/scaling/zk-rollups/), ale neukládá transakční data na Ethereum Mainnet. Ačkoli off-chain dostupnost dat přináší určité kompromisy, může vést k masivnímu zlepšení škálovatelnosti (validium může zpracovat přibližně [9 000 nebo více transakcí za sekundu](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). +Validium je [škalovací řešení](/developers/docs/scaling/), které zajišťuje integritu transakcí pomocí důkazů o platnosti, podobně jako [ZK-rollupy](/developers/docs/scaling/zk-rollups/), ale neukládá transakční data na Ethereum Mainnet. Ačkoli dostupnost dat off-chain přináší kompromisy, může vést k masivnímu zlepšení škálovatelnosti (validia mohou zpracovat [~9 000 transakcí za sekundu nebo více](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). ## 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 je to validium? {#what-is-validium} -Validia jsou škálovací řešení, která využívají off-chain dostupnost dat a výpočty navržené ke zlepšení propustnosti zpracováním transakcí mimo Ethereum Mainnet. Stejně jako zero-knowledge rollupy (ZK-rollupy) zveřejňují validia [důkazy s nulovou znalostí](/glossary/#zk-proof) k ověření transakcí mimo řetězec Etherea. Tím se zabraňuje neplatným změnám stavu a zvyšují se bezpečnostní záruky řetězce typu validium. +Validia jsou škálovací řešení, která využívají off-chain dostupnost dat a výpočty navržené ke zlepšení propustnosti zpracováním transakcí mimo Ethereum Mainnet. Stejně jako rollupy s nulovou znalostí (ZK-rollupy), validia zveřejňují [důkazy s nulovou znalostí](/glossary/#zk-proof) k ověření off-chain transakcí na Ethereu. Tím se zabraňuje neplatným změnám stavu a zvyšují se bezpečnostní záruky řetězce typu validium. Tyto „důkazy o platnosti“ mohou mít podobu ZK-SNARKů (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) nebo ZK-STARKů (Zero-Knowledge Scalable Transparent Argument of Knowledge). Více o [důkazech s nulovou znalostí](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/). -Prostředky patřící uživatelům validia jsou spravovány smart kontraktem na Ethereu. Validium nabízí téměř okamžité výběry, podobně jako ZK-rollupy; jakmile je důkaz o platnosti žádosti o výběr ověřen na Mainnetu, uživatelé mohou vybrat prostředky poskytnutím [Merkle důkazů](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). Merkle důkaz ověřuje zahrnutí výběrové transakce uživatele do ověřeného balíku transakcí, což umožňuje on-chain kontraktu zpracovat výběr. +Prostředky patřící uživatelům validia jsou spravovány smart kontraktem na Ethereu. Validia nabízejí téměř okamžité výběry, podobně jako ZK-rollupy; jakmile je důkaz o platnosti žádosti o výběr ověřen na Mainnetu, uživatelé mohou vybrat prostředky poskytnutím [Merkleho důkazů](/developers/tutorials/merkle-proofs-for-offline-data-integrity/). Merkleho důkaz ověřuje zahrnutí výběrové transakce uživatele do ověřeného balíku transakcí, což umožňuje on-chain kontraktu zpracovat výběr. Nicméně uživatelé validia mohou mít své prostředky zmrazené a výběry omezené. To se může stát, pokud správci dostupnosti dat na validiovém řetězci zadrží off-chain stavová data od uživatelů. Bez přístupu k transakčním datům nemohou uživatelé vytvořit Merkle důkaz potřebný k prokázání vlastnictví prostředků a k provedení výběru. @@ -25,21 +25,21 @@ Toto je hlavní rozdíl mezi validiem a ZK-rollupy – jejich pozice na spektru ## Jak validia interagují s Ethereem? {#how-do-validiums-interact-with-ethereum} -Validia jsou škálovací protokoly postavené na stávajícím řetězci Etherea. Ačkoli provádí transakce mimo řetězec, validiový řetězec je spravován sadou smart kontraktů nasazených na Mainnetu, včetně: +Validia jsou škálovací protokoly postavené na stávajícím řetězci Etherea. Ačkoli provádí transakce off-chain, validiový řetězec je spravován sadou chytrých kontraktů nasazených na Mainnetu, včetně: -1. **Ověřovacího kontraktu**: Ověřovací kontrakt ověřuje platnost důkazů předložených operátorem validia při provádění aktualizací stavu. To zahrnuje důkazy o platnosti potvrzující správnost transakcí mimo řetězec a důkazy o dostupnosti dat, které ověřují existenci off-chain transakčních dat. +1. **Ověřovací kontrakt**: Ověřovací kontrakt ověřuje platnost důkazů předložených operátorem validia při provádění aktualizací stavu. To zahrnuje důkazy o platnosti potvrzující správnost off-chain transakcí a důkazy o dostupnosti dat, které ověřují existenci off-chain transakčních dat. -2. **Hlavního kontraktu**: Hlavní kontrakt ukládá závazky ke stavu (Merkle kořeny) předložené producenty bloků a aktualizuje stav validia, jakmile je na řetězci ověřen důkaz o platnosti. Tento kontrakt také zpracovává vklady a výběry z validiového řetězce. +2. **Hlavní kontrakt**: Hlavní kontrakt ukládá závazky ke stavu (Merkleho kořeny) předložené producenty bloků a aktualizuje stav validia, jakmile je on-chain ověřen důkaz o platnosti. Tento kontrakt také zpracovává vklady a výběry z validiového řetězce. Validia se spoléhají na hlavní vrstvu Etherea v následujících bodech: -### Vyrovnání {#settlement} +### Vypořádání {#settlement} -Transakce provedené na validiu nemohou být plně potvrzeny, dokud rodičovský řetězec neověří jejich platnost. Veškeré obchodní transakce provedené na validiu musí být nakonec vypořádány na Mainnetu. Blockchain Etherea také poskytuje „záruky vypořádání“ pro uživatele validia, což znamená, že transakce mimo řetězec nemohou být zvráceny nebo změněny, jakmile jsou potvrzeny on-chain. +Transakce provedené na validiu nemohou být plně potvrzeny, dokud rodičovský řetězec neověří jejich platnost. Veškeré obchodní transakce provedené na validiu musí být nakonec vypořádány na Mainnetu. Blockchain Etherea také poskytuje „záruky vypořádání“ pro uživatele validia, což znamená, že off-chain transakce nemohou být zvráceny nebo změněny, jakmile jsou potvrzeny on-chain. ### Bezpečnost {#security} -Ethereum, které funguje jako vrstva sloužící k vypořádání, také zaručuje platnost přechodů stavu na validiu. Transakce mimo řetězec provedené na validiovém řetězci jsou ověřovány prostřednictvím smart kontraktu na základní vrstvě Etherea. +Ethereum, které funguje jako vrstva sloužící k vypořádání, také zaručuje platnost přechodů stavu na validiu. Off-chain transakce provedené na validiovém řetězci jsou ověřovány prostřednictvím chytrého kontraktu na základní vrstvě Etherea. Pokud on-chain ověřovací kontrakt shledá důkaz neplatným, jsou transakce zamítnuty. To znamená, že operátoři musí splnit podmínky platnosti vynucené protokolem Etherea před aktualizací stavu validia. @@ -47,7 +47,7 @@ Pokud on-chain ověřovací kontrakt shledá důkaz neplatným, jsou transakce z ### Transakce {#transactions} -Uživatelé předkládají transakce operátorovi, což je síťový uzel zodpovědný za provádění transakcí na validiu. Některá validia mohou používat k exekuci řetězce jediného operátora nebo se pro rotaci operátorů spoléhat na mechanismus [proof of stake (PoS)](/developers/docs/consensus-mechanisms/pos/). +Uživatelé předkládají transakce operátorovi, což je síťový uzel zodpovědný za provádění transakcí na validiu. Některá validia mohou používat k exekuci řetězce jediného operátora nebo se pro rotaci operátorů spoléhat na mechanismus [důkazu podílem (PoS)](/developers/docs/consensus-mechanisms/pos/). Operátor agreguje transakce do balíku a odešle je do ověřovacího okruhu k potvrzení. Ověřovací okruh přijme balík transakcí (a další relevantní data) jako vstupy a výstupem je důkaz o platnosti, který ověřuje, že operace byly provedeny správně. @@ -65,21 +65,21 @@ Pro přesun prostředků zpět na Mainnet zahájí uživatel validia transakci v Jako mechanismus proti cenzuře umožňuje validiový protokol uživatelům vybírat přímo z validiového kontraktu bez použití operátora. V tomto případě musí uživatelé poskytnout Merkle důkaz ověřovacímu kontraktu, který prokazuje zahrnutí účtu do kořene stavu. Pokud je důkaz přijat, uživatel může zavolat funkci pro výběr z hlavního kontraktu a vybrat své prostředky z validia. -### Podání balíčku {#batch-submission} +### Dávkové odesílání {#batch-submission} Po exekuci balíčku transakcí předloží operátor přidružený důkaz o platnosti ověřovacímu kontraktu a navrhne nový kořen stavu hlavnímu kontraktu. Pokud je důkaz platný, hlavní kontrakt aktualizuje stav validia a finalizuje výsledky transakcí v balíku. -Na rozdíl od ZK-rollupu nejsou producenti bloků na validiu povinni zveřejňovat transakční data pro balíky transakcí (pouze záhlaví bloků). To dělá z validia čistě off-chain škálovací protokol, na rozdíl od „hybridních“ škálovacích protokolů (tj. [vrstva 2](/layer-2/)), které zveřejňují stavová data na hlavním řetězci Etherea jako `calldata`. +Na rozdíl od ZK-rollupu nejsou producenti bloků na validiu povinni zveřejňovat transakční data pro balíky transakcí (pouze záhlaví bloků). To dělá z validia čistě off-chain škálovací protokol, na rozdíl od „hybridních“ škálovacích protokolů (tj. [vrstva 2](/layer-2/)), které zveřejňují stavová data na hlavním řetězci Etherea pomocí dat typu blob, `calldata`, nebo jejich kombinací. ### Dostupnost dat {#data-availability} -Jak už jsme zmínili, validia využívají off-chain model dostupnosti dat, kde operátoři ukládají veškerá transakční data mimo Ethereum Mainnet. Malá on-chain datová stopa validia zlepšuje škálovatelnost (propustnost není omezena kapacitou zpracování dat na Ethereu) a snižuje poplatky uživatelů (náklady na publikování `calldata` jsou nižší). +Jak už jsme zmínili, validia využívají off-chain model dostupnosti dat, kde operátoři ukládají veškerá transakční data mimo Ethereum Mainnet. Nízká on-chain datová stopa validia zlepšuje škálovatelnost (propustnost není omezena kapacitou zpracování dat Etherea) a snižuje poplatky uživatelů (náklady na publikování dat on-chain jsou nižší). -Off-chain dostupnost dat však představuje problém: Data nezbytná k vytvoření nebo ověření Merkle důkazů mohou být nedostupná. To znamená, že uživatelé nemusí být schopni vybrat prostředky z on-chain kontraktu, pokud by operátoři podváděli. +Off-chain dostupnost dat však představuje problém: data nezbytná k vytvoření nebo ověření Merkleho důkazů mohou být nedostupná. To znamená, že uživatelé nemusí být schopni vybrat prostředky z on-chain kontraktu, pokud by operátoři jednali se zlým úmyslem. -Různá řešení validií se pokoušejí tento problém vyřešit decentralizací úložiště stavových dat. To zahrnuje tlak na producenty bloků, aby zasílali základní data „správcům dostupnosti dat,“ kteří jsou zodpovědní za ukládání off-chain dat a zpřístupnění uživatelům na požádání. +Různá řešení validií se pokoušejí tento problém vyřešit decentralizací úložiště stavových dat. Spočívá to v donucení producentů bloků posílat podkladová data „správcům dostupnosti dat“, kteří jsou odpovědní za ukládání off-chain dat a jejich zpřístupnění uživatelům na vyžádání. -Správci dostupnosti dat ve validiu potvrzují dostupnost dat pro transakce mimo řetězec tím, že podepisují každý balík validia. Tyto podpisy představují formu „důkazu dostupnosti,“ který ověřovací kontrakt na řetězci kontroluje před schválením aktualizací stavu. +Správci dostupnosti dat ve validiu potvrzují dostupnost dat pro off-chain transakce tím, že podepisují každý balík validia. Tyto podpisy představují formu „důkazu dostupnosti“, který on-chain ověřovací kontrakt kontroluje před schválením aktualizací stavu. Validia se liší v přístupu ke správě dostupnosti dat. Některá se spoléhají na důvěryhodné strany pro ukládání stavových dat, zatímco jiná využívají náhodně přidělené validátory. @@ -87,19 +87,19 @@ Validia se liší v přístupu ke správě dostupnosti dat. Některá se spoléh Pro zajištění dostupnosti off-chain dat jmenují některá validiová řešení skupinu důvěryhodných subjektů, společně známou jako komise pro dostupnost dat (DAC), která ukládá kopie stavu a poskytuje důkazy o dostupnosti dat. DAC jsou snazší na implementaci a vyžadují méně koordinace, protože členství je omezené. -Uživatelé však musí věřit DAC, že data budou k dispozici, když budou potřeba (např. pro generování Merkle důkazů). Existuje možnost, že členové komise [budou kompromitováni podvodníkem](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view), který pak může zadržovat off-chain data. +Uživatelé však musí věřit DAC, že data budou k dispozici, když budou potřeba (např. pro generování Merkle důkazů). Existuje možnost, že členové komisí pro dostupnost dat [budou kompromitováni útočníkem](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view), který pak může zadržovat off-chain data. -[Více o komisi pro dostupnost dat na validiu](https://medium.com/starkware/data-availability-e5564c416424). +[Více o komisích pro dostupnost dat ve validiích](https://medium.com/starkware/data-availability-e5564c416424). -#### Dostupnost vázaných dat {#bonded-data-availability} +#### Vázaná dostupnost dat {#bonded-data-availability} Jiná validia vyžadují, aby účastníci zodpovědní za ukládání offline dat před převzetím své role zastavili (tj. uzamkli) tokeny ve smart kontraktu. Tento stake slouží jako „závazek“ k zajištění čestného chování mezi správci dostupnosti dat a snižuje potřebu důvěry. Pokud tito účastníci nedokážou prokázat dostupnost dat, jejich záloha se zmenší. -V rámci schématu dostupnosti vázaných dat může být kdokoli pověřen držením off-chain dat, pokud poskytne požadovaný stake. To rozšiřuje okruh způsobilých správců dostupnosti dat a snižuje centralizaci, která ovlivňuje komisi pro dostupnost dat (DAC). Důležitější je, že tento přístup spoléhá na kryptoekonomické incentivy, které brání podvodné aktivitě, což je podstatně bezpečnější než jmenování důvěryhodných stran pro zajištění offline dat ve validiu. +V rámci schématu vázané dostupnosti dat může být kdokoli pověřen držením off-chain dat, pokud poskytne požadovaný stake. To rozšiřuje okruh způsobilých správců dostupnosti dat a snižuje centralizaci, která ovlivňuje komisi pro dostupnost dat (DAC). Důležitější je, že tento přístup spoléhá na kryptoekonomické incentivy, které brání podvodné aktivitě, což je podstatně bezpečnější než jmenování důvěryhodných stran pro zajištění offline dat ve validiu. -[Více o dostupnosti vázaných dat na validiu](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). +[Více o vázané dostupnosti dat ve validiích](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). -## Volitia a validium {#volitions-and-validium} +## Volitions a validium {#volitions-and-validium} Validium nabízí mnoho výhod, ale přináší i kompromisy (nejvýrazněji v oblasti dostupnosti dat). Stejně jako u mnoha škálovacích řešení je validium vhodné pro specifické případy použití – právě proto byla vytvořena volitia. @@ -109,57 +109,58 @@ Decentralizovaná burza (DEX) může preferovat použití škálovatelné a souk ## Validia a kompatibilita s EVM {#validiums-and-evm-compatibility} -Stejně jako ZK-rollupy jsou validia většinou vhodná pro jednoduché aplikace, jako jsou směny tokenů a platby. Podpora obecného výpočtu a exekuce smart kontraktů na validiu je obtížná na implementaci vzhledem ke značné režii při ověřování instrukcí [EVM](/developers/docs/evm/) v zero-knowledge důkazním okruhu. +Stejně jako ZK-rollupy jsou validia většinou vhodná pro jednoduché aplikace, jako jsou směny tokenů a platby. Podpora obecných výpočtů a provádění chytrých kontraktů na validiích je obtížně implementovatelná vzhledem ke značné režii při dokazování instrukcí [EVM](/developers/docs/evm/) v důkazním okruhu s nulovou znalostí. Některé validiové projekty se pokoušejí tento problém obejít kompilací jazyků kompatibilních s EVM (např. Solidity, Vyper) do vytváření vlastního bytecode optimalizovaného pro efektivní ověřování. Nevýhodou tohoto přístupu je, že nové virtuální stroje přátelské k důkazům s nulovou znalostí nemusí podporovat důležité opkódy EVM a vývojáři musí psát přímo v high-level jazyce. To vytváří ještě více problémů: Nutí vývojáře stavět dappky s úplně novým vývojovým stackem a narušuje kompatibilitu se stávající infrastrukturou Etherea. -Některé týmy se však pokoušejí optimalizovat stávající opkódy EVM pro ZK-důkazní kruhy. To povede k vývoji virtuálního stroje Etherea s nulovou znalostí (zkEVM), virtuálního stroje kompatibilního s EVM, který generuje důkazy pro ověření správnosti exekuce programů. Se zkEVM mohou validiové řetězce exekuovat smart kontrakty mimo řetězec a předkládat důkazy o platnosti k ověření off-chain výpočtů (bez nutnosti je znovu provádět) na Ethereu. +Některé týmy se však pokoušejí optimalizovat stávající opkódy EVM pro ZK-důkazní kruhy. To povede k vývoji virtuálního stroje Etherea s nulovou znalostí (zkEVM), virtuálního stroje kompatibilního s EVM, který generuje důkazy pro ověření správnosti exekuce programů. Se zkEVM mohou validiové řetězce provádět chytré kontrakty off-chain a předkládat důkazy o platnosti k ověření off-chain výpočtů (bez nutnosti je znovu provádět) na Ethereu. [Více o zkEVM](https://www.alchemy.com/overviews/zkevm). ## Jak validia škálují Ethereum? {#scaling-ethereum-with-validiums} -### 1. Off-chain úložiště dat {#off-chain-data-storage} +### 1. Off-chain úložiště dat {#offchain-data-storage} -Škálovací projekty vrstvy 2, jako jsou optimistické rollupy a ZK-rollupy, vyměňují nekonečnou škálovatelnost čistě off-chain škálovacích protokolů (např. [Plasma](/developers/docs/scaling/plasma/)) za bezpečnost tím, že publikují některá transakční data na vrstvě 1. To však znamená, že škálovatelnost rollupů je omezena šířkou pásma dat na Ethereum Mainnetu ([sharding dat](/roadmap/danksharding/) si klade za cíl zlepšit kapacitu úložiště dat na Ethereu právě z tohoto důvodu). +Škálovací projekty vrstvy 2, jako jsou optimistické rollupy a ZK-rollupy, vyměňují nekonečnou škálovatelnost čistě off-chain škálovacích protokolů (např. [Plasma](/developers/docs/scaling/plasma/)) za bezpečnost tím, že publikují některá transakční data na L1. To však znamená, že škálovatelnost rollupů je omezena šířkou pásma dat na Ethereum Mainnetu ([sharding dat](/roadmap/danksharding/) si z tohoto důvodu klade za cíl zlepšit kapacitu úložiště dat Etherea). -Validia dosahují škálovatelnosti tím, že udržují všechna transakční data mimo řetězec a publikují pouze závazky stavu (a důkazy o platnosti) při přenosu aktualizací stavu na hlavní řetězec Etherea. Existence důkazů o platnosti však poskytuje validiu vyšší bezpečnostní záruky než jiná čistě off-chain škálovací řešení, včetně Plasmy a [postranních řetězců](/developers/docs/scaling/sidechains/). Snížením množství dat, která musí Ethereum zpracovat před ověřením transakcí mimo řetězec, validiové návrhy výrazně zvyšují propustnost na Mainnetu. +Validia dosahují škálovatelnosti tím, že udržují všechna transakční data off-chain a publikují pouze závazky stavu (a důkazy o platnosti) při přenosu aktualizací stavu na hlavní řetězec Etherea. Existence důkazů o platnosti však dává validiím vyšší bezpečnostní záruky než jiná čistě off-chain škálovací řešení, včetně Plasmy a [sidechainů](/developers/docs/scaling/sidechains/). Snížením množství dat, která musí Ethereum zpracovat před ověřením off-chain transakcí, validiové návrhy výrazně zvyšují propustnost na Mainnetu. ### 2. Rekurzivní důkazy {#recursive-proofs} Rekurzivní důkaz je důkaz o platnosti, který ověřuje platnost jiných důkazů. Tyto „důkazy důkazů“ jsou generovány rekurzivním agregováním více důkazů, dokud není vytvořen jeden konečný důkaz, který ověřuje všechny předchozí důkazy. Rekurzivní důkazy škálují rychlost zpracování blockchainu tím, že zvyšují počet transakcí, které mohou být ověřeny na jeden důkaz o platnosti. -Obvykle každý důkaz o platnosti, který operátor validia předloží k ověření Ethereu, ověřuje integritu jednoho bloku. Na druhou stranu lze jeden rekurzivní důkaz použít k potvrzení platnosti několika bloků validia současně – je to možné, protože ověřovací okruh může rekurzivně agregovat několik blokových důkazů do jednoho konečného důkazu. Pokud ověřovací kontrakt na řetězci přijme rekurzivní důkaz, všechny podkladové bloky jsou okamžitě finalizovány. +Obvykle každý důkaz o platnosti, který operátor validia předloží k ověření Ethereu, ověřuje integritu jednoho bloku. Na druhou stranu lze jeden rekurzivní důkaz použít k potvrzení platnosti několika bloků validia současně – je to možné, protože ověřovací okruh může rekurzivně agregovat několik blokových důkazů do jednoho konečného důkazu. Pokud on-chain ověřovací kontrakt přijme rekurzivní důkaz, všechny podkladové bloky jsou okamžitě finalizovány. ## Výhody a nevýhody validia {#pros-and-cons-of-validium} -| Plusy | Mínusy | -| ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Důkazy o platnosti zajišťují integritu transakcí mimo řetězec a zabraňují operátorům finalizovat neplatné aktualizace stavu. | Výroba důkazů o platnosti vyžaduje speciální hardware, což představuje riziko centralizace. | -| Zvyšuje efektivitu kapitálu pro uživatele (žádné zpoždění při výběru prostředků zpět na Ethereum). | Omezená podpora pro obecné výpočty a smart kontrakty; pro vývoj jsou nutné specializované jazyky. | -| Není náchylné k určitým ekonomickým útokům, kterým čelí systémy založené na důkazech podvodu u aplikací s vysokou hodnotou. | Vyžaduje vysoký výpočetní výkon pro generování ZK důkazů; není nákladově efektivní pro aplikace s nízkou propustností. | -| Snižuje poplatky za palivo pro uživatele tím, že neposílá calldata na Ethereum Mainnet. | Pomalejší subjektivní finálnost (10–30 minut na vytvoření ZK důkazu), ale rychlejší k úplné finálnosti, protože při řešení sporů není žádné zpoždění. | -| Vhodné pro specifické případy použití, jako je obchodování nebo blockchainové hry, které upřednostňují soukromí transakcí a škálovatelnost. | Uživatelé mohou mít zablokovaný výběr prostředků, protože generování Merkle důkazů o vlastnictví vyžaduje, aby off-chain data byla dostupná po celou dobu. | -| Dostupnost dat mimo řetězec poskytuje vyšší úroveň propustnosti a zvyšuje škálovatelnost. | Bezpečnostní model spoléhá na důvěru a kryptoekonomické incentivy, na rozdíl od ZK-rollupů, které se spoléhají čistě na kryptografické bezpečnostní mechanismy. | +| Plusy | Minusy | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Důkazy o platnosti zajišťují integritu off-chain transakcí a zabraňují operátorům finalizovat neplatné aktualizace stavu. | Výroba důkazů o platnosti vyžaduje speciální hardware, což představuje riziko centralizace. | +| Zvyšuje efektivitu kapitálu pro uživatele (žádné zpoždění při výběru prostředků zpět na Ethereum). | Omezená podpora pro obecné výpočty a smart kontrakty; pro vývoj jsou nutné specializované jazyky. | +| Není náchylné k určitým ekonomickým útokům, kterým čelí systémy založené na důkazech podvodu u aplikací s vysokou hodnotou. | Vyžaduje vysoký výpočetní výkon pro generování ZK důkazů; není nákladově efektivní pro aplikace s nízkou propustností. | +| Snižuje poplatky za palivo pro uživatele tím, že neposílá calldata na Ethereum Mainnet. | Pomalejší subjektivní finálnost (10–30 minut na vytvoření ZK důkazu), ale rychlejší k úplné finálnosti, protože při řešení sporů není žádné zpoždění. | +| Vhodné pro specifické případy použití, jako je obchodování nebo blockchainové hry, které upřednostňují soukromí transakcí a škálovatelnost. | Uživatelé mohou mít zablokovaný výběr prostředků, protože generování Merkleho důkazů o vlastnictví vyžaduje, aby off-chain data byla dostupná po celou dobu. | +| Dostupnost dat off-chain poskytuje vyšší úroveň propustnosti a zvyšuje škálovatelnost. | Bezpečnostní model spoléhá na důvěru a kryptoekonomické incentivy, na rozdíl od ZK-rollupů, které se spoléhají čistě na kryptografické bezpečnostní mechanismy. | -### Použití validia a volitia {#use-validium-and-volitions} +### Použití Validium/Volitions {#use-validium-and-volitions} Několik projektů poskytuje implementace validia a volitia, které můžete integrovat do svých dapp: -**StarkWare StarkEx** – _StarkEx je škálovací řešení pro Ethereum druhé vrstvy (L2), které je založeno na důkazech o platnosti. Může fungovat buď v ZK-Rollup, nebo validium režimu dostupnosti dat._ +**StarkWare StarkEx** - _StarkEx je škálovací řešení pro Ethereum vrstvy 2 (L2), které je založeno na důkazech o platnosti. Může fungovat buď v ZK-Rollup, nebo validium režimu dostupnosti dat._ - [Dokumentace](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) -- [Web](https://starkware.co/starkex/) +- [Webové stránky](https://starkware.co/starkex/) -**Matter Labs zkPorter** – _zkPorter je škálovací protokol druhé vrstvy, který řeší dostupnost dat hybridním přístupem, který kombinuje myšlenky zkRollupu a shardingu. Může podporovat libovolný počet shardů, každý s vlastní politikou dostupnosti dat._ +**Matter Labs zkPorter**- _zkPorter je škálovací protokol vrstvy 2, který řeší dostupnost dat hybridním přístupem, který kombinuje myšlenky zkRollupu a shardingu. Může podporovat libovolný počet shardů, každý s vlastní politikou dostupnosti dat._ - [Blog](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) - [Dokumentace](https://docs.zksync.io/zksync-protocol/rollup/data-availability) -- [Web](https://zksync.io/) +- [Webové stránky](https://zksync.io/) -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Validium And The Layer 2 Two-By-Two — Issue No. 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) -- [ZK-rollupy versus Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [Validium a matice 2x2 vrstvy 2 — vydání č. 99](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [ZK-rollupy vs. Validium](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) - [Volition a vznikající spektrum dostupnosti dat](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) -- [Rollupy, validia a volitia: Seznamte se s nejžhavějšími škálovacími řešeními pro Ethereum](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Rollupy, validia a volitions: Poznejte nejžhavější řešení pro škálování Etherea](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) +- [Praktický průvodce rollupy na Ethereu](https://web.archive.org/web/20241108192208/https://research.2077.xyz/the-practical-guide-to-ethereum-rollups) From 2e89bdcc7e2a1b88f84fa037214ce5d947d8c825 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sun, 15 Feb 2026 15:54:52 +0000 Subject: [PATCH 2/2] fix(i18n): correct translation issues in Czech files --- .../developers/docs/nodes-and-clients/index.md | 2 +- .../cs/developers/docs/oracles/index.md | 16 ++++++++-------- .../cs/developers/docs/scaling/index.md | 4 ++-- .../docs/scaling/optimistic-rollups/index.md | 4 ++-- .../cs/developers/docs/scaling/plasma/index.md | 2 +- .../docs/scaling/state-channels/index.md | 2 +- .../cs/developers/docs/scaling/validium/index.md | 2 +- 7 files changed, 16 insertions(+), 16 deletions(-) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/index.md index 5f143703cd5..d65ad4905f6 100644 --- a/public/content/translations/cs/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/index.md @@ -1,5 +1,5 @@ --- -title: " Uzly a klienty" +title: "Uzly a klienti" description: "Přehled uzlů a klientského softwaru Etherea, plus jak nastavit uzel a proč byste to měli dělat." lang: cs sidebarDepth: 2 diff --git a/public/content/translations/cs/developers/docs/oracles/index.md b/public/content/translations/cs/developers/docs/oracles/index.md index 974b3af2d04..ed80328eaba 100644 --- a/public/content/translations/cs/developers/docs/oracles/index.md +++ b/public/content/translations/cs/developers/docs/oracles/index.md @@ -6,13 +6,13 @@ lang: cs Oracles jsou aplikace, které vytvářejí datové kanály, jež zpřístupňují blockchainu pro smart kontrakty offchainové datové zdroje. To je nezbytné, protože smart kontrakty založené na Ethereu nemohou ve výchozím nastavení přistupovat k informacím uloženým mimo blockchainovou síť. -Poskytnutí možnosti smart kontraktům provádět operace s využitím offchainových dat rozšiřuje užitečnost a hodnotu decentralizovaných aplikací. Například onchainové predikční trhy se spoléhají na oracles, které jim poskytují informace o výsledcích, jež používají k ověření předpovědí uživatelů. Představme si, že Alice vsadí 20 ETH na to, kdo se stane příštím prezidentem USA. V takovém případě bude predikční aplikace potřebovat orákulum, které potvrdí výsledky voleb a určilí, zda má Alice nárok na výplatu. +Poskytnutí možnosti smart kontraktům provádět operace s využitím offchainových dat rozšiřuje užitečnost a hodnotu decentralizovaných aplikací. Například onchainové predikční trhy se spoléhají na oracles, které jim poskytují informace o výsledcích, jež používají k ověření předpovědí uživatelů. Představme si, že Alice vsadí 20 ETH na to, kdo se stane příštím prezidentem USA. V takovém případě bude predikční aplikace potřebovat orákulum, které potvrdí výsledky voleb a určí, zda má Alice nárok na výplatu. ## Předpoklady {#prerequisites} Tato stránka předpokládá, že je čtenář obeznámen se základy Etherea, včetně [uzlů](/developers/docs/nodes-and-clients/), [mechanismů konsenzu](/developers/docs/consensus-mechanisms/) a [EVM](/developers/docs/evm/). Měli byste také dobře rozumět [smart kontraktům](/developers/docs/smart-contracts/) a [anatomii smart kontraktů](/developers/docs/smart-contracts/anatomy/), zejména [událostem](/glossary/#events). -## Co je blockchainové orákulum? Co je to blockchain oracle? {#what-is-a-blockchain-oracle} +## Co je blockchainové orákulum? {#what-is-a-blockchain-oracle} Oracles jsou aplikace, které získávají, ověřují a přenášejí externí informace (tj. informace uložené mimo blockchain) do smart kontraktů běžících na blockchainu. Kromě „tahání“ offchainových dat a jejich vysílání na Ethereu mohou oracles také „tlačit“ informace z blockchainu do externích systémů, např. odemknutí chytrého zámku, jakmile uživatel odešle poplatek prostřednictvím transakce na Ethereu. @@ -24,7 +24,7 @@ Orákula se liší podle zdroje dat (jeden nebo více zdrojů), modelů důvěry Mnoho vývojářů vidí smart kontrakty jako kód běžící na specifických adresách na blockchainu. Obecnější [pohled na smart kontrakty](/smart-contracts/) je však takový, že se jedná o samočinně se provádějící softwarové programy, které jsou schopny vynucovat dohody mezi stranami, jakmile jsou splněny určité podmínky – odtud pochází termín „smart kontrakty“. -Použití smart kontraktů k vynucování dohod mezi lidmi však není jednoduché, vzhledem k tomu, že Ethereum je deterministické. [Deterministický systém](https://en.wikipedia.org/wiki/Deterministic_algorithm) je takový systém, který při daném počátečním stavu a konkrétním vstupu vždy produkuje stejné výsledky, což znamená, že v procesu výpočtu výstupů ze vstupů není žiadna náhodnost ani variace. +Použití smart kontraktů k vynucování dohod mezi lidmi však není jednoduché, vzhledem k tomu, že Ethereum je deterministické. [Deterministický systém](https://en.wikipedia.org/wiki/Deterministic_algorithm) je takový systém, který při daném počátečním stavu a konkrétním vstupu vždy produkuje stejné výsledky, což znamená, že v procesu výpočtu výstupů ze vstupů není žádná náhodnost ani variace. Pro dosažení deterministického provádění omezují blockchainy uzly na dosažení konsenzu u jednoduchých binárních otázek (pravda/nepravda) s použitím _pouze_ dat uložených na samotném blockchainu. Příklady takových otázek zahrnují: @@ -42,7 +42,7 @@ Za tímto účelem se oracle obvykle skládá ze smart kontraktu běžícího on Orákulum v podstatě překlenuje informační propast mezi blockchainem a externím prostředím a vytváří „hybridní smart kontrakty“. Hybridní smart kontrakt je takový, který funguje na základě kombinace kódu onchainového kontraktu a offchainové infrastruktury. Decentralizované predikční trhy jsou vynikajícím příkladem hybridních smart kontraktů. Dalšími příklady mohou být smart kontrakty určené k pojištění plodin, které vyplácejí pojistné plnění, když určitá orákula určí, že došlo k určitému meteorologickému jevu. -## Jaké problémy se s orákuly pojí? Problém oracles {#the-oracle-problem} +## Jaké problémy se s orákuly pojí? {#the-oracle-problem} Orákula řeší důležitý problém, ale zároveň přinášejí některé komplikace, např.,: @@ -60,7 +60,7 @@ Různá orákula nabízejí různé způsoby řešení problému orákulí, kter 3. **Kompatibilita pobídek**: Oracle by měl motivovat offchainové poskytovatele dat k předkládání správných informací smart kontraktům. Kompatibilita pobídek zahrnuje _přiřaditelnost_ a _odpovědnost_. Možnost přiřazení umožňuje spojit externí informaci s jejím poskytovatelem, zatímco odpovědnost váže poskytovatele dat k informacím, které poskytují, aby mohli být odměněni nebo potrestáni na základě kvality poskytnutých informací. -## Jak funguje služba blockchainového orákula? Jak funguje služba blockchain oracle? {#how-does-a-blockchain-oracle-service-work} +## Jak funguje služba blockchainového orákula? {#how-does-a-blockchain-oracle-service-work} ### Uživatelé {#users} @@ -198,7 +198,7 @@ contract Oracle { ### Uzly oraclu {#oracle-nodes} -Uzel oraclu je offchainová komponenta služby oraclu. Získává informace z externích zdrojů, jako jsou API hostované на serverech třetích stran, a ukládá je onchain pro využití smart kontrakty. Uzly oraclu naslouchají událostem z onchainového kontraktu oraclu a přistupují k dokončení úkolu popsaného v protokolu. +Uzel oraclu je offchainová komponenta služby oraclu. Získává informace z externích zdrojů, jako jsou API hostované na serverech třetích stran, a ukládá je onchain pro využití smart kontrakty. Uzly oraclu naslouchají událostem z onchainového kontraktu oraclu a přistupují k dokončení úkolu popsaného v protokolu. Běžným úkolem uzlů oraclu je odeslání požadavku [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) službě API, parsování odpovědi za účelem extrakce relevantních dat, jejich formátování do výstupu čitelného pro blockchain a odeslání onchain zahrnutím do transakce do kontraktu oraclu. Orákulový uzel může být také povinen potvrdit platnost a integritu předkládaných informací pomocí „důkazů autenticity“, které prozkoumáme později. @@ -236,7 +236,7 @@ U centralizovaných oraclů není zaručeno, že budou offchainová data vždy d #### Špatná kompatibilita pobídek {#poor-incentive-compatibility} -Centralizovaná orákula často nemají dobře navržené motivace (případně nemajjí vůbec žádné motivace) pro poskytovatele dat, nemohou tak zaručit, že jim budou zasílat přesné a nepozměněné informace. Platba za správnost orákula nezaručuje jeho poctivost. Tento problém se zhoršuje, jakmile se zvýší hodnota, kterou smart kontrakty spravují. +Centralizovaná orákula často nemají dobře navržené motivace (případně nemají vůbec žádné motivace) pro poskytovatele dat, nemohou tak zaručit, že jim budou zasílat přesné a nepozměněné informace. Platba za správnost orákula nezaručuje jeho poctivost. Tento problém se zhoršuje, jakmile se zvýší hodnota, kterou smart kontrakty spravují. ### Decentralizované oracles {#decentralized-oracles} @@ -292,7 +292,7 @@ Mechanismy Schelling point jsou atraktivní, protože minimalizují onchainovou Decentralizované služby oraclů zajišťují vysokou dostupnost offchainových dat pro smart kontrakty. Toho je dosaženo decentralizací jak zdroje offchainových informací, tak uzlů odpovědných za přenos informací onchain. -Tím je zajišťema odolnost proti chybám, protože orákulový kontrakt se při plnění dotazů z jiných kontraktů může spolehnout na více uzlů (které se také spoléhají na více zdrojů dat). Decentralizace na úrovni zdroje _a_ operátorů uzlů je klíčová – síť uzlů oraclu poskytujících informace získané ze stejného zdroje se dostane do stejného problému jako centralizovaný oracle. +Tím je zajištěna odolnost proti chybám, protože orákulový kontrakt se při plnění dotazů z jiných kontraktů může spolehnout na více uzlů (které se také spoléhají na více zdrojů dat). Decentralizace na úrovni zdroje _a_ operátorů uzlů je klíčová – síť uzlů oraclu poskytujících informace získané ze stejného zdroje se dostane do stejného problému jako centralizovaný oracle. Je také možné, aby oracly založené na stakování trestaly operátory uzlů, kteří na požadavky o data nereagují dostatečně rychle. To výrazně motivuje orákulové uzly investovat do infrastruktury odolné proti chybám a poskytovat data včas. diff --git a/public/content/translations/cs/developers/docs/scaling/index.md b/public/content/translations/cs/developers/docs/scaling/index.md index 1aef8c745b4..02f9a0b6f6f 100644 --- a/public/content/translations/cs/developers/docs/scaling/index.md +++ b/public/content/translations/cs/developers/docs/scaling/index.md @@ -25,7 +25,7 @@ On-chain škálování vyžaduje změny v protokolu Ethereum (vrstva 1 [Mainnet] ### Sharding {#sharding} -Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardery, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí [plánu](/roadmap/) Etherea a původně se počítalo s jeho spuštěním před přechodem na proof-of-stake (The Merge). Rychlý vývoj [rollupů vrstvy 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání datových blobů z rollupů do bloků Etherea, které mohou validátoři velmi efektivně ověřit) však vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto škálování pomocí shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší. +Sharding je proces rozdělení databáze. Podskupiny validátorů by byly zodpovědné za jednotlivé shardy, místo aby sledovaly celé Ethereum. Sharding byl dlouhou dobu součástí [plánu](/roadmap/) Etherea a původně se počítalo s jeho spuštěním před přechodem na proof-of-stake (The Merge). Rychlý vývoj [rollupů vrstvy 2](#layer-2-scaling) a vynález [Dankshardingu](/roadmap/danksharding) (přidávání datových blobů z rollupů do bloků Etherea, které mohou validátoři velmi efektivně ověřit) však vedly komunitu Etherea k upřednostnění škálování zaměřeného na rollupy namísto škálování pomocí shardingu. To také pomůže udržet logiku konsensu Etherea jednodušší. ## Off-chain škálování {#offchain-scaling} @@ -89,7 +89,7 @@ Zjistěte více o [Validium](/developers/docs/scaling/validium/). - Celek je efektivnější než součet efektivity jeho částí. Různá řešení mohou existovat a pracovat v harmonii, což aplikuje exponenciální efekt na budoucí rychlost transakcí a propustnost. - Ne všechna řešení vyžadují přímé využití konsensuálního algoritmu Etherea a alternativy mohou nabízet výhody, které by jinak bylo obtížné získat. -## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} +## Učíte se spíše vizuálně? {#visual-learner} diff --git a/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md index b8bc8f49c07..1c16f2000d6 100644 --- a/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/cs/developers/docs/scaling/optimistic-rollups/index.md @@ -1,6 +1,6 @@ --- title: "Optimistické rollupy" -description: "Úvod do optimistických rollapů – řešení pro škálování, které používá komunita Etherea." +description: "Úvod do optimistických rollupů – řešení pro škálování, které používá komunita Etherea." lang: cs --- @@ -26,7 +26,7 @@ Pokud důkaz podvodu uspěje, protokol rollupu transakce znovu provede a podle t Pokud balíček rollupu zůstane bez výzvy (tj. všechny transakce jsou správně provedeny) po skončení časového okna, je považován za platný a přijatý na Ethereum. Ostatní mohou nadále stavět na nepotvrzeném bloku rollupu, ale s podmínkou: Výsledky transakcí budou zrušeny, pokud budou založeny na nesprávně provedené transakci. -## Jak optimistické rollupy interagují s Ethereum? Jak optimistické rollupy škálují Ethereum? {#optimistic-rollups-and-Ethereum} +## Jak optimistické rollupy interagují s Ethereem? {#optimistic-rollups-and-Ethereum} Optimistické rollupy jsou [řešení pro škálování mimo řetězec](/developers/docs/scaling/#offchain-scaling) navržená k provozu nad Ethereem. Každý optimistický rollup je spravován sadou smart kontraktů nasazených na síti Ethereum. Optimistické rollupy zpracovávají transakce mimo hlavní řetězec Ethereum, ale odesílají transakce mimo řetězec (v balíčcích) do rollupového kontraktu na řetězci. Stejně jako blockchain Ethereum je tento záznam transakcí neměnný a tvoří „optimistický rollupový řetězec“. diff --git a/public/content/translations/cs/developers/docs/scaling/plasma/index.md b/public/content/translations/cs/developers/docs/scaling/plasma/index.md index 1e73944799d..61a49c49ee5 100644 --- a/public/content/translations/cs/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/cs/developers/docs/scaling/plasma/index.md @@ -18,7 +18,7 @@ Měli byste dobře rozumět všem základním tématům a mít obecný přehled Plasma je vývojová platforma pro zlepšení škálovatelnosti na veřejných blockchainech, jako je Ethereum. Jak je popsáno v původní [bílé knize Plasma](http://plasma.io/plasma.pdf), jsou plasma řetězce postaveny na jiném blockchainu (nazývaném „kořenový řetězec“). Každý „dceřiný řetězec“ se rozšiřuje z kořenového řetězce a je obecně spravován smart kontraktem nasazeným na mateřském řetězci. -Kontrakt Plasma funguje mimo jiné jako [přemostění](/developers/docs/bridges/), které umožňuje uživatelům přesouvat aktiva mezi hlavní sítí Ethereum a plazmovým řetězcem. Ačkoli je to činí podobnými [sidechainům](/developers/docs/scaling/sidechains/), plazmové řetězce těží – alespoň do určité míry – z bezpečnosti hlavní sítě Ethereum. A tím se od postranním řetězců, které jsou zodpovědné za svou bezpečnost samy, odlišují. +Kontrakt Plasma funguje mimo jiné jako [přemostění](/developers/docs/bridges/), které umožňuje uživatelům přesouvat aktiva mezi hlavní sítí Ethereum a plazmovým řetězcem. Ačkoli je to činí podobnými [sidechainům](/developers/docs/scaling/sidechains/), plazmové řetězce těží – alespoň do určité míry – z bezpečnosti hlavní sítě Ethereum. A tím se od postranních řetězců, které jsou zodpovědné za svou bezpečnost samy, odlišují. ## Jak Plasma funguje? diff --git a/public/content/translations/cs/developers/docs/scaling/state-channels/index.md b/public/content/translations/cs/developers/docs/scaling/state-channels/index.md index 69ce9d16023..4185b27eb90 100644 --- a/public/content/translations/cs/developers/docs/scaling/state-channels/index.md +++ b/public/content/translations/cs/developers/docs/scaling/state-channels/index.md @@ -253,7 +253,7 @@ Několik projektů poskytuje implementace stavových kanálů, které můžete i **Stavové kanály** -- [Porozumění škalovacím řešením na vrstvě 2 Etherea: Stavové kanály, Plasma a Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, 12. února 2018_ +- [Porozumění škálovacím řešením na vrstvě 2 Etherea: Stavové kanály, Plasma a Truebit](https://medium.com/l4-media/making-sense-of-ethereums-layer-2-scaling-solutions-state-channels-plasma-and-truebit-22cb40dcc2f4) _– Josh Stark, 12. února 2018_ - [Stavové kanály - vysvětlení](https://www.jeffcoleman.ca/state-channels/) _6. listopadu 2015 – Jeff Coleman_ - [Základy stavových kanálů](https://education.district0x.io/general-topics/understanding-ethereum/basics-state-channels/) _District0x_ - [Stavové kanály na blockchainu: Špička blockchainu](https://ieeexplore.ieee.org/document/9627997) diff --git a/public/content/translations/cs/developers/docs/scaling/validium/index.md b/public/content/translations/cs/developers/docs/scaling/validium/index.md index ee11448177a..a57cbce0df9 100644 --- a/public/content/translations/cs/developers/docs/scaling/validium/index.md +++ b/public/content/translations/cs/developers/docs/scaling/validium/index.md @@ -5,7 +5,7 @@ lang: cs sidebarDepth: 3 --- -Validium je [škalovací řešení](/developers/docs/scaling/), které zajišťuje integritu transakcí pomocí důkazů o platnosti, podobně jako [ZK-rollupy](/developers/docs/scaling/zk-rollups/), ale neukládá transakční data na Ethereum Mainnet. Ačkoli dostupnost dat off-chain přináší kompromisy, může vést k masivnímu zlepšení škálovatelnosti (validia mohou zpracovat [~9 000 transakcí za sekundu nebo více](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). +Validium je [škálovací řešení](/developers/docs/scaling/), které zajišťuje integritu transakcí pomocí důkazů o platnosti, podobně jako [ZK-rollupy](/developers/docs/scaling/zk-rollups/), ale neukládá transakční data na Ethereum Mainnet. Ačkoli dostupnost dat off-chain přináší kompromisy, může vést k masivnímu zlepšení škálovatelnosti (validia mohou zpracovat [~9 000 transakcí za sekundu nebo více](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). ## Předpoklady {#prerequisites}