diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md new file mode 100644 index 00000000000..dc56d41c063 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/index.md @@ -0,0 +1,92 @@ +--- +title: Mechanismy konsenzu +description: "Vysvětlení konsensuálních protokolů v distribuovaných systémech a jejich role v Ethereu." +lang: cs +--- + +Pojem „mechanismus konsenzu“ se často hovorově používá pro protokoly „důkaz podílem“, „důkaz prací“ nebo „důkaz autoritou“. Jedná se však pouze o součásti mechanismů konsenzu, které chrání proti [útokům Sybil](/glossary/#sybil-attack). Mechanismy konsenzu jsou kompletní soubor myšlenek, protokolů a pobídek, které umožňují distribuované sadě uzlů dohodnout se na stavu blockchainu. + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky doporučujeme si nejprve přečíst náš [úvod do Etherea](/developers/docs/intro-to-ethereum/). + +## Co je to konsensus? {#what-is-consensus} + +Konsensem myslíme, že bylo dosaženo všeobecné shody. Představte si skupinu lidí, kteří jdou do kina. Pokud nedojde k neshodě ohledně navrhovaného výběru filmu, je dosaženo konsensu. Pokud dojde k neshodě, skupina musí mít prostředky, jak se rozhodnout, na který film se podívat. V krajních případech se skupina nakonec rozdělí. + +Pokud jde o blockchain Etherea, proces je formalizován a dosažení konsensu znamená, že se alespoň 66 % uzlů v síti shodne na globálním stavu sítě. + +## Co je to konsensuální mechanismus? {#what-is-a-consensus-mechanism} + +Termín mechanismus konsenzu se vztahuje na celý soubor protokolů, pobídek a myšlenek, které umožňují síti uzlů dohodnout se na stavu blockchainu. + +Ethereum používá mechanismus konsenzu založený na důkazu podílem, který odvozuje své krypto-ekonomické zabezpečení ze souboru odměn a pokut uplatňovaných na kapitál uzamčený stakery. Tato motivační struktura povzbuzuje jednotlivé stakery, aby provozovali poctivé validátory, trestá ty, kteří tak nečiní, a vytváří extrémně vysoké náklady na útok na síť. + +Dále existuje protokol, který řídí, jak jsou poctiví validátoři vybíráni, aby navrhovali nebo validovali bloky, zpracovávali transakce a hlasovali pro svůj pohled na začátek řetězce. Ve vzácných situacích, kdy se v blízkosti začátku řetězce nachází více bloků ve stejné pozici, existuje mechanismus výběru větve, který vybírá bloky, které tvoří „nejtěžší“ řetězec, měřeno počtem validátorů, kteří pro bloky hlasovali, váženým jejich zůstatkem vsazeného etheru. + +Některé koncepty jsou pro konsensus důležité, ale nejsou explicitně definovány v kódu, jako například dodatečné zabezpečení, které nabízí potenciální mimopásmová sociální koordinace jako poslední obranná linie proti útokům na síť. + +Tyto komponenty dohromady tvoří mechanismus konsenzu. + +## Typy mechanismů konsenzu {#types-of-consensus-mechanisms} + +### Založené na důkazu prací {#proof-of-work} + +Stejně jako Bitcoin, i Ethereum kdysi používalo konsensuální protokol založený na **důkazu prací (PoW)**. + +#### Tvorba bloku {#pow-block-creation} + +Těžaři soutěží o vytvoření nových bloků naplněných zpracovanými transakcemi. Vítěz se o nový blok podělí se zbytkem sítě a získá čerstvě vytěžené ETH. Závod vyhrává počítač, který dokáže nejrychleji vyřešit matematickou hádanku. Tím se vytvoří kryptografické spojení mezi aktuálním blokem a blokem, který mu předcházel. Vyřešení této hádanky je ona „práce“ v „důkazu prací“. Kanonický řetězec je pak určen pravidlem výběru větve, které vybírá sadu bloků, na jejichž vytěžení bylo vynaloženo nejvíce práce. + +#### Bezpečnost {#pow-security} + +Síť je bezpečná díky tomu, že k podvodu v řetězci byste potřebovali 51% výpočetního výkonu sítě. To by vyžadovalo tak obrovské investice do vybavení a energie, že byste pravděpodobně utratili více, než byste získali. + +Více o [důkazu prací](/developers/docs/consensus-mechanisms/pow/) + +### Založené na důkazu podílem {#proof-of-stake} + +Ethereum nyní používá konsensuální protokol založený na **důkazu podílem (PoS)**. + +#### Tvorba bloku {#pos-block-creation} + +Validátoři vytvářejí bloky. V každém slotu je náhodně vybrán jeden validátor, který se stane navrhovatelem bloku. Jejich konsensuální klient si vyžádá balíček transakcí jako „exekuční datovou část“ od spárovaného exekučního klienta. Toto zabalí do konsensuálních dat, aby vytvořili blok, který odešlou ostatním uzlům v síti Ethereum. Tato produkce bloků je odměňována v ETH. Ve vzácných případech, kdy pro jeden slot existuje více možných bloků nebo se uzly o blocích dozvědí v různou dobu, algoritmus výběru větve vybere blok, který tvoří řetězec s největší váhou atestací (kde váha je počet atestujících validátorů škálovaný jejich zůstatkem ETH). + +#### Bezpečnost {#pos-security} + +Systém důkazu podílem je krypto-ekonomicky bezpečný, protože útočník, který se pokusí převzít kontrolu nad řetězcem, musí zničit obrovské množství ETH. Systém odměn motivuje jednotlivé stakery k čestnému chování a pokuty je odrazují od škodlivého jednání. + +Více o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) + +### Vizuální průvodce {#types-of-consensus-video} + +Podívejte se na více informací o různých typech mechanismů konsenzu používaných v Ethereu: + + + +### Odolnost proti útokům Sybil a výběr řetězce {#sybil-chain} + +Důkaz prací a důkaz podílem samy o sobě nejsou konsensuální protokoly, ale pro zjednodušení se tak často označují. Jsou to ve skutečnosti mechanismy odolnosti proti útokům Sybil a voliči autora bloku; je to způsob, jak rozhodnout, kdo je autorem nejnovějšího bloku. Další důležitou součástí je algoritmus pro výběr řetězce (neboli výběr větve), který umožňuje uzlům vybrat si jeden jediný správný blok na začátku řetězce ve scénářích, kdy na stejné pozici existuje více bloků. + +**Odolnost proti útokům Sybil** měří, jak si protokol vede proti útoku Sybil. Odolnost proti tomuto typu útoku je pro decentralizovaný blockchain zásadní a umožňuje těžařům a validátorům, aby byli odměňováni rovnoměrně na základě vložených zdrojů. Důkaz prací a důkaz podílem proti tomu chrání tím, že nutí uživatele vynaložit velké množství energie nebo vložit velký kolaterál. Tato ochrana je ekonomickým odstrašujícím prostředkem proti útokům Sybil. + +**Pravidlo výběru řetězce** se používá k rozhodnutí, který řetězec je ten „správný“. Bitcoin používá pravidlo „nejdelšího řetězce“, což znamená, že nejdelší blockchain bude ten, který zbytek uzlů přijme jako platný a bude s ním pracovat. U řetězců s důkazem prací je nejdelší řetězec určen celkovou kumulativní obtížností důkazu prací daného řetězce. I Ethereum dříve používalo pravidlo nejdelšího řetězce; nicméně nyní, když Ethereum běží na důkazu podílem, přijalo aktualizovaný algoritmus výběru větve, který měří „váhu“ řetězce. Váha je kumulativní součet hlasů validátorů, vážený zůstatky vsazeného etheru validátorů. + +Ethereum používá mechanismus konsenzu známý jako [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/), který kombinuje [důkaz podílem Casper FFG](https://arxiv.org/abs/1710.09437) s [pravidlem výběru větve GHOST](https://arxiv.org/abs/2003.03052). + +## Další čtení {#further-reading} + +- [Co je to konsensuální algoritmus blockchainu?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) +- [Co je to Nakamoto konsensus? Kompletní průvodce pro začátečníky](https://blockonomi.com/nakamoto-consensus/) +- [Jak funguje Casper?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [O bezpečnosti a výkonu blockchainů s důkazem prací](https://eprint.iacr.org/2016/555.pdf) +- [Byzantská chyba](https://en.wikipedia.org/wiki/Byzantine_fault) + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Související témata {#related-topics} + +- [Důkaz prací](/developers/docs/consensus-mechanisms/pow/) +- [Těžba](/developers/docs/consensus-mechanisms/pow/mining/) +- [Důkaz podílem](/developers/docs/consensus-mechanisms/pos/) +- [Důkaz autoritou](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/poa/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/poa/index.md new file mode 100644 index 00000000000..a7464ae2afa --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/poa/index.md @@ -0,0 +1,80 @@ +--- +title: Proof-of-authority (PoA) +description: "Vysvětlení konsenzuálního protokolu proof-of-authority a jeho role v ekosystému blockchainu." +lang: cs +--- + +**Proof-of-authority (PoA)** je konsenzuální algoritmus založený na reputaci, který je upravenou verzí [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). Většinou se používá na privátních řetězcích, testnetech a lokálních vývojových sítích. PoA je konsenzuální algoritmus založený na reputaci, který k vytváření bloků vyžaduje důvěru v sadu autorizovaných podepisovatelů, a to na rozdíl od mechanismu PoS založeného na podílu. + +## Předpoklady {#prerequisites} + +Abyste lépe porozuměli této stránce, doporučujeme vám si nejprve přečíst o [transakcích](/developers/docs/transactions/), [blocích](/developers/docs/blocks/) a [mechanismech konsenzu](/developers/docs/consensus-mechanisms/). + +## Co je to proof-of-authority (PoA)? {#what-is-poa} + +Proof-of-authority je upravená verze **[důkazu podílem](/developers/docs/consensus-mechanisms/pos/) (PoS)**, což je konsenzuální algoritmus založený na reputaci namísto mechanismu PoS založeného na podílu. Tento termín poprvé představil v roce 2017 Gavin Wood a tento konsenzuální algoritmus se většinou používá na privátních řetězcích, testnetech a lokálních vývojových sítích, jelikož překonává potřebu vysoce kvalitních zdrojů jako PoW a řeší problémy se škálovatelností u PoS tím, že pouze malá podmnožina uzlů ukládá blockchain a vytváří bloky. + +Proof-of-authority vyžaduje důvěru v sadu autorizovaných podepisovatelů, kteří jsou definováni v [genesis bloku](/glossary/#genesis-block). Ve většině současných implementací si všichni autorizovaní podepisovatelé ponechávají stejnou moc a oprávnění při určování konsensu řetězce. Myšlenka stakování reputace je taková, že každý autorizovaný validátor je všem dobře známý, například prostřednictvím ověření klienta (KYC) nebo tím, že jediným validátorem je známá organizace. Tímto způsobem je v případě, že validátor udělá něco špatně, jeho identita známa. + +Existuje několik implementací PoA, ale standardní implementací Etherea je **clique**, která implementuje [EIP-225](https://eips.ethereum.org/EIPS/eip-225). Clique je standard přívětivý pro vývojáře a snadno se implementuje, přičemž podporuje všechny typy synchronizace klientů. Mezi další implementace patří [IBFT 2.0](https://besu.hyperledger.org/private-networks/concepts/poa) a [Aura](https://openethereum.github.io/Chain-specification). + +## Jak to funguje {#how-it-works} + +V PoA je k vytváření nových bloků vybrána sada autorizovaných podepisovatelů. Podepisovatelé jsou vybíráni na základě své reputace a jsou jediní, kdo smí vytvářet nové bloky. Podepisovatelé jsou vybíráni cyklicky (způsobem round-robin) a každý podepisovatel smí vytvořit blok v určitém časovém rámci. Doba vytváření bloku je pevně daná a podepisovatelé musí vytvořit blok v tomto časovém rámci. + +Reputace v tomto kontextu není kvantifikovatelná veličina, ale spíše reputace známých korporací, jako je Microsoft nebo Google. Z toho důvodu výběr důvěryhodných podepisovatelů není algoritmický, ale je to normální lidský akt _důvěry_. Když například entita jako Microsoft vytvoří privátní síť PoA pro stovky nebo tisíce startupů a sama se ujme role jediného důvěryhodného podepisovatele s možností v budoucnu přidat další známé podepisovatele, jako je Google, startupy by bezpochyby důvěřovaly společnosti Microsoft, že bude vždy jednat čestně, a síť by používaly. Tím se řeší nutnost stakovat v různých malých/soukromých sítích, které byly vytvořeny pro různé účely, aby zůstaly decentralizované a funkční, a zároveň se eliminuje potřeba těžařů, což spotřebovává velké množství energie a zdrojů. Některé privátní sítě, jako například VeChain, používají standard PoA v jeho původní podobě a některé ho upravují, jako například Binance, která používá [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa), což je vlastní upravená verze PoA a PoS. + +Hlasovací proces provádějí sami podepisovatelé. Každý podepisovatel hlasuje pro přidání nebo odebrání podepisovatele ve svém bloku, když vytváří nový blok. Uzly sečtou hlasy a podepisovatelé jsou přidáni nebo odebráni na základě toho, zda hlasy dosáhnou určitého prahu `SIGNER_LIMIT`. + +Může nastat situace, kdy dojde k malým větvím. Obtížnost bloku závisí na tom, zda byl blok podepsán v pořadí, nebo mimo pořadí. Bloky „v pořadí“ mají obtížnost 2 a bloky „mimo pořadí“ mají obtížnost 1. V případě malých větví získá největší celkovou obtížnost a vyhraje ten řetězec, ve kterém většina podepisovatelů potvrzuje bloky „v pořadí“. + +## Vektory útoku {#attack-vectors} + +### Zlomyslní podepisovatelé {#malicious-signers} + +Do seznamu podepisovatelů by mohl být přidán zlomyslný uživatel nebo by mohl být kompromitován podpisový klíč/stroj. V takovém scénáři se protokol musí být schopen bránit proti reorganizacím a spamování. Navrhovaným řešením je, že na seznamu N autorizovaných podepisovatelů může každý podepisovatel razit pouze 1 blok z každých K. To zajišťuje omezení škod a zbytek validátorů může zlomyslného uživatele odhlasovat. + +### Cenzura {#censorship-attack} + +Dalším zajímavým vektorem útoku je, když se podepisovatel (nebo skupina podepisovatelů) pokusí cenzurovat bloky, které hlasují o jejich odstranění ze seznamu autorizací. Aby se tomu předešlo, je povolená frekvence ražení bloků podepisovateli omezena na 1 z N/2. To zajišťuje, že zlomyslní podepisovatelé musí ovládat alespoň 51 % podepisovacích účtů. V takovém případě by se fakticky stali novým zdrojem pravdy pro řetězec. + +### Spam {#spam-attack} + +Dalším menším vektorem útoku je, když zlomyslní podepisovatelé vkládají nové návrhy na hlasování do každého bloku, který razí. Protože uzly musí sečíst všechny hlasy, aby vytvořily skutečný seznam autorizovaných podepisovatelů, musí v průběhu času zaznamenávat všechny hlasy. Bez omezení hlasovacího okna by tento počet mohl pomalu, ale neomezeně růst. Řešením je zavést _pohyblivé_ okno W bloků, po kterém jsou hlasy považovány za zastaralé. _Přiměřené okno může být 1–2 epochy._ + +### Souběžné bloky {#concurrent-blocks} + +V síti PoA, kde je N autorizovaných podepisovatelů, smí každý podepisovatel razit 1 blok z K, což znamená, že v daném okamžiku smí razit blok N-K+1 validátorů. Aby se zabránilo tomu, že tito validátoři budou soutěžit o bloky, měl by každý podepisovatel přidat malý náhodný "offset" k času, kdy uvolní nový blok. Ačkoli tento proces zajišťuje, že malé větve jsou vzácné, občasné větve se stále mohou vyskytnout, stejně jako na hlavní síti. Pokud se zjistí, že podepisovatel zneužívá svou moc a způsobuje chaos, mohou ho ostatní podepisovatelé odhlasovat. + +Pokud je například 10 autorizovaných podepisovatelů a každý podepisovatel smí vytvořit 1 blok z 20, pak v daném okamžiku může 11 validátorů vytvářet bloky. Aby se zabránilo tomu, že budou soutěžit o vytváření bloků, každý podepisovatel přidá malý náhodný "offset" k času, kdy uvolní nový blok. To snižuje výskyt malých větví, ale stále umožňuje občasné větve, jak je vidět na hlavní síti Etherea. Pokud podepisovatel zneužije svou autoritu a způsobí narušení, může být odhlasován ze sítě. + +## Výhody a nevýhody {#pros-and-cons} + +| Plusy | Minusy | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Škálovatelnější než jiné populární mechanismy jako PoS a PoW, protože je založen na omezeném počtu podepisovatelů bloků. | Sítě PoA mají obvykle relativně malý počet ověřovacích uzlů. Díky tomu je síť PoA více centralizovaná. | +| Provoz a údržba blockchainů PoA je neuvěřitelně levná. | Stát se autorizovaným podepisovatelem je pro běžného člověka obvykle nedostupné, protože blockchain vyžaduje entity se zavedenou reputací. | +| Transakce jsou potvrzovány velmi rychle, může to být i za méně než 1 sekundu, protože k ověření nových bloků je zapotřebí pouze omezený počet podepisovatelů. | Zlomyslní podepisovatelé by mohli provést reorganizaci, dvojí útratu, cenzurovat transakce v síti. Tyto útoky jsou sice zmírněny, ale stále možné. | + +## Další čtení {#further-reading} + +- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _standard Clique_ +- [Studie Proof of Authority](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_ +- [Co je to Proof of Authority](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_ +- [Vysvětlení Proof of Authority](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_ +- [PoA v blockchainu](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba) +- [Vysvětlení Clique](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d) +- [Zastaralé PoA, specifikace Aura](https://openethereum.github.io/Chain-specification) +- [IBFT 2.0, další implementace PoA](https://besu.hyperledger.org/private-networks/concepts/poa) + +### Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} + +Podívejte se na vizuální vysvětlení proof-of-authority: + + + +## Související témata {#related-topics} + +- [Důkaz prací](/developers/docs/consensus-mechanisms/pow/) +- [Důkaz podílem](/developers/docs/consensus-mechanisms/pos/) + diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md new file mode 100644 index 00000000000..ee56598ac30 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -0,0 +1,166 @@ +--- +title: "Útok a obrana na ethereový důkaz podílem" +description: "Zjistěte více o známých vektorech útoku na Ethereum s důkazem podílem a o tom, jaká je proti nim obrana." +lang: cs +--- + +Zloději a sabotéři neustále hledají příležitosti k útoku na klientský software Etherea. Tato stránka popisuje známé vektory útoku na konsensuální vrstvu Etherea a popisuje, jak se těmto útokům bránit. Informace na této stránce jsou převzaty z [delší verze](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs). + +## Předpoklady {#prerequisites} + +Vyžadují se základní znalosti [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). Také je užitečné mít základní znalosti o ethereové [vrstvě pobídek](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) a algoritmu pro výběr větve, [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper). + +## Co útočníci chtějí? {#what-do-attackers-want} + +Běžnou mylnou představou je, že úspěšný útočník může vytvářet nový ether nebo odčerpávat ether z libovolných účtů. Nic z toho není možné, protože všechny transakce jsou prováděny všemi exekučními klienty v síti. Musí splňovat základní podmínky platnosti (např. transakce jsou podepsány soukromým klíčem odesílatele, odesílatel má dostatečný zůstatek atd.), jinak se jednoduše vrátí. Existují tři třídy výsledků, na které se může útočník realisticky zaměřit: reorganizace, dvojí finalita nebo zpoždění finality. + +**„Reorganizace“** je přeskupení bloků do nového pořadí, případně s přidáním nebo odebráním některých bloků v kanonickém řetězci. Škodlivá reorganizace může zajistit zahrnutí nebo vyloučení konkrétních bloků, což umožňuje dvojí útratu nebo extrakci hodnoty prostřednictvím front-runningu a back-runningu transakcí (MEV). Reorganizace by se také mohly použít k zabránění zahrnutí určitých transakcí do kanonického řetězce – což je forma cenzury. Nejextrémnější formou reorganizace je „vrácení finality“, které odstraňuje nebo nahrazuje bloky, jež byly dříve finalizovány. To je možné pouze v případě, že více než ⅓ celkového stakovaného etheru je zničeno útočníkem – tato záruka je známá jako „ekonomická finalita“ – o tom více později. + +**Dvojí finalita** je nepravděpodobný, ale závažný stav, kdy se dvě větve dokáží finalizovat současně, což vytvoří trvalé rozdělení v řetězci. To je teoreticky možné pro útočníka, který je ochoten riskovat 34 % celkového stakovaného etheru. Komunita by byla nucena se koordinovat mimo řetězec a dohodnout se, kterou větev bude následovat, což by vyžadovalo sílu sociální vrstvy. + +Útok **zpožděním finality** brání síti v dosažení nezbytných podmínek pro finalizaci úseků řetězce. Bez finality je těžké důvěřovat finančním aplikacím postaveným na Ethereu. Cílem útoku zpožděním finality je pravděpodobně jen narušit Ethereum, než přímý zisk, pokud útočník nemá nějaké strategické krátké pozice. + +Útok na sociální vrstvu může mít za cíl podkopat důvěru veřejnosti v Ethereum, znehodnotit ether, snížit adopci nebo oslabit komunitu Etherea, aby byla externí koordinace obtížnější. + +Poté, co jsme si ujasnili, proč by protivník mohl zaútočit na Ethereum, následující části se zabývají tím, _jak_ by to mohl udělat. + +## Metody útoku {#methods-of-attack} + +### Útoky na 0. vrstvu {#layer-0} + +Především jednotlivci, kteří se aktivně neúčastní na Ethereu (provozováním klientského softwaru), mohou útočit na sociální vrstvu (0. vrstvu). 0. vrstva je základ, na kterém je Ethereum postaveno, a jako taková představuje potenciální plochu pro útoky s důsledky, které se šíří zbytkem stacku. Některé příklady mohou zahrnovat: + +- Dezinformační kampaň by mohla narušit důvěru komunity v plán Etherea, týmy vývojářů, aplikace atd. To by pak mohlo snížit počet jednotlivců ochotných se podílet na zabezpečení sítě, což by narušilo decentralizaci i kryptoekonomickou bezpečnost. + +- Cílené útoky a/nebo zastrašování zaměřené na komunitu vývojářů. To by mohlo vést k dobrovolnému odchodu vývojářů a zpomalit pokrok Etherea. + +- Příliš horlivá regulace by také mohla být považována za útok na 0. vrstvu, protože by mohla rychle odradit od účasti a přijetí. + +- Infiltrace znalých, ale škodlivých aktérů do komunity vývojářů, jejichž cílem je zpomalit pokrok diskusemi o nepodstatných detailech, oddalováním klíčových rozhodnutí, vytvářením spamu atd. + +- Úplatky klíčovým hráčům v ekosystému Etherea za účelem ovlivnění rozhodování. + +Co dělá tyto útoky obzvláště nebezpečnými, je skutečnost, že v mnoha případech je zapotřebí jen velmi malý kapitál nebo technické know-how. Útok na 0. vrstvu by mohl být násobitelem kryptoekonomického útoku. Pokud by například cenzury nebo vrácení finality bylo dosaženo škodlivým většinovým držitelem, podkopání sociální vrstvy by mohlo ztížit koordinaci komunitní reakce mimo běžné kanály. + +Obrana proti útokům na 0. vrstvu pravděpodobně není jednoduchá, ale lze stanovit některé základní principy. Jedním z nich je udržování celkově vysokého poměru signálu k šumu u veřejných informací o Ethereu, vytvářených a šířených poctivými členy komunity prostřednictvím blogů, serverů na Discordu, anotovaných specifikací, knih, podcastů a YouTube. Zde na ethereum.org se usilovně snažíme udržovat přesné informace a překládat je do co nejvíce jazyků. Zaplavení prostoru vysoce kvalitními informacemi a memy je účinnou obranou proti dezinformacím. + +Dalším důležitým opevněním proti útokům na sociální vrstvu je jasné poslání a protokol správy. Ethereum se etablovalo jako šampion v decentralizaci a bezpečnosti mezi 1. vrstvami s chytrými kontrakty, přičemž si také vysoce cení škálovatelnosti a udržitelnosti. Ať už v komunitě Etherea vzniknou jakékoli neshody, tyto základní principy jsou ohroženy jen minimálně. Posuzování narativu oproti těmto základním principům a jeho zkoumání v postupných kolech revize v procesu EIP (Ethereum Improvement Proposal) může komunitě pomoci rozlišit dobré aktéry od špatných a omezuje prostor pro škodlivé aktéry, aby ovlivňovali budoucí směřování Etherea. + +A konečně, je zásadní, aby komunita Etherea zůstala otevřená a vstřícná vůči všem účastníkům. Komunita s vrátnými a exkluzivitou je obzvláště zranitelná vůči sociálním útokům, protože je snadné vytvářet narativy „my a oni“. Tribalismus a toxický maximalismus poškozují komunitu a narušují bezpečnost 0. vrstvy. Ethereané s osobním zájmem na bezpečnosti sítě by měli své chování online a v reálném světě vnímat jako přímý příspěvek k bezpečnosti 0. vrstvy Etherea. + +### Útok na protokol {#attacking-the-protocol} + +Kdokoli může provozovat klientský software Etherea. Pro přidání validátora ke klientovi musí uživatel stakovat 32 etherů do depozitního kontraktu. Validátor umožňuje uživateli aktivně se podílet na bezpečnosti sítě Ethereum navrhováním a atestováním nových bloků. Validátor má nyní hlas, který může použít k ovlivnění budoucího obsahu blockchainu – může to dělat poctivě a navyšovat svou zásobu etheru prostřednictvím odměn, nebo se může pokusit manipulovat procesem ve svůj vlastní prospěch a riskovat svůj stake. Jedním ze způsobů, jak provést útok, je nashromáždit větší podíl celkového staku a poté ho použít k přehlasování poctivých validátorů. Čím větší je podíl staku ovládaný útočníkem, tím větší je jeho hlasovací síla, zejména při určitých ekonomických milnících, které prozkoumáme později. Většina útočníků však nebude schopna nashromáždit dostatek etheru k takovému útoku, takže místo toho musí používat jemné techniky k manipulaci poctivé většiny, aby jednala určitým způsobem. + +V zásadě jsou všechny útoky s malým stakem jemnými variacemi dvou typů nesprávného chování validátorů: nedostatečná aktivita (neúspěšná atestace/navržení nebo jejich pozdní provedení) nebo nadměrná aktivita (navrhování/atestování příliš mnohokrát v jednom slotu). V nejzákladnějších formách se s těmito akcemi snadno vypořádá algoritmus volby větve a vrstva pobídek, ale existují chytré způsoby, jak systém zneužít ve prospěch útočníka. + +### Útoky pomocí malého množství ETH {#attacks-by-small-stakeholders} + +#### Reorganizace {#reorgs} + +Několik studií vysvětlilo útoky na Ethereum, které dosahují reorganizace nebo zpoždění finality pouze s malým podílem celkového stakovaného etheru. Tyto útoky obecně spoléhají na to, že útočník zadrží některé informace před ostatními validátory a poté je uvolní nějakým rafinovaným způsobem a/nebo v nějakém vhodném okamžiku. Obvykle se zaměřují na vytlačení některých poctivých bloků z kanonického řetězce. [Neuder a kol. 2020](https://arxiv.org/pdf/2102.02247.pdf) ukázali, jak může útočící validátor vytvořit a atestovat blok (`B`) pro konkrétní slot `n+1`, ale zdržet se jeho šíření ostatním uzlům v síti. Místo toho si ponechá atestovaný blok až do dalšího slotu `n+2`. Poctivý validátor navrhne blok (`C`) pro slot `n+2`. Téměř současně může útočník uvolnit svůj zadržený blok (`B`) a své zadržené atestace pro něj a také atestovat `B` jako hlavu řetězce svými hlasy pro slot `n+2`, čímž účinně popře existenci poctivého bloku `C`. Když je uvolněn poctivý blok `D`, algoritmus volby větve vidí, že `D` postavený na `B` má větší váhu než `D` postavený na `C`. Útočník tedy dokázal odstranit poctivý blok `C` ve slotu `n+2` z kanonického řetězce pomocí ex ante reorganizace jednoho bloku. [Útočník s 34%](https://www.youtube.com/watch?v=6vzXwwk12ZE) staku má velmi dobrou šanci na úspěch v tomto útoku, jak je vysvětleno [v této poznámce](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair). Teoreticky by se však tento útok mohl pokusit i s menšími staky. [Neuder a kol. 2020](https://arxiv.org/pdf/2102.02247.pdf) popsali tento útok fungující s 30% stakem, ale později se ukázalo, že je životaschopný s [2 % celkového staku](https://arxiv.org/pdf/2009.04987.pdf) a poté znovu pro [jednoho validátora](https://arxiv.org/abs/2110.10086#) pomocí vyrovnávacích technik, které prozkoumáme v další části. + +![ex-ante reorganizace](reorg-schematic.png) + +Koncepční diagram útoku reorganizací jednoho bloku popsaný výše (převzato z https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) + +Sofistikovanější útok může rozdělit sadu poctivých validátorů do diskrétních skupin, které mají různé pohledy na hlavu řetězce. To je známé jako **vyrovnávací útok**. Útočník čeká na svou šanci navrhnout blok, a když se naskytne, provede ekvivokaci a navrhne dva. Jeden blok pošle jedné polovině sady poctivých validátorů a druhý blok druhé polovině. Ekvivokace by byla detekována algoritmem výběru větve a navrhovatel bloku by byl potrestán (slashed) a vyloučen ze sítě, ale oba bloky by stále existovaly a měly by asi polovinu sady validátorů atestujících pro každou větev. Mezitím zbývající škodliví validátoři zadržují své atestace. Poté selektivním uvolněním atestací ve prospěch jedné či druhé větve právě pro dostatek validátorů v okamžiku, kdy se spustí algoritmus volby větve, převáží kumulativní váhu atestací ve prospěch jedné či druhé větve. To může pokračovat neomezeně, přičemž útočící validátoři udržují rovnoměrné rozdělení validátorů mezi oběma větvemi. Vzhledem k tomu, že žádná větev nemůže přilákat dvoutřetinovou nadpoloviční většinu, síť by se nefinalizovala. + +**Odrazové útoky** jsou podobné. Hlasy jsou opět zadrženy útočícími validátory. Místo uvolnění hlasů, aby se udrželo rovnoměrné rozdělení mezi dvěma větvemi, používají své hlasy ve vhodných okamžicích k ospravedlnění kontrolních bodů, které se střídají mezi větví A a větví B. Toto přeskakování ospravedlnění mezi dvěma větvemi brání tomu, aby existovaly páry ospravedlněných zdrojových a cílových kontrolních bodů, které by mohly být finalizovány na obou řetězcích, což zastaví finalitu. + + + +Odrazové i vyrovnávací útoky spoléhají na to, že útočník má velmi jemnou kontrolu nad časováním zpráv v síti, což je nepravděpodobné. Nicméně v protokolu jsou zabudovány obrany ve formě dodatečného vážení daného rychlým zprávám ve srovnání s pomalými. To je známé jako [posílení váhy navrhovatele](https://github.com/ethereum/consensus-specs/pull/2730). Pro obranu proti odrazovým útokům byl algoritmus volby větve aktualizován tak, aby se nejnovější ospravedlněný kontrolní bod mohl přepnout na alternativní řetězec pouze během [první 1/3 slotů v každé epoše](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114). Tato podmínka brání útočníkovi, aby si šetřil hlasy na pozdější nasazení – algoritmus volby větve jednoduše zůstane věrný kontrolnímu bodu, který si vybral v první 1/3 epochy, během níž by většina poctivých validátorů hlasovala. + +Dohromady tato opatření vytvářejí scénář, kdy poctivý navrhovatel bloku vydá svůj blok velmi rychle po začátku slotu, poté následuje období ~1/3 slotu (4 sekundy), kdy tento nový blok může způsobit, že algoritmus volby větve přejde na jiný řetězec. Po uplynutí stejného termínu jsou atestace, které přicházejí od pomalých validátorů, váženy méně než ty, které dorazily dříve. To silně upřednostňuje rychlé navrhovatele a validátory při určování hlavy řetězce a podstatně snižuje pravděpodobnost úspěšného vyrovnávacího nebo odrazového útoku. + +Stojí za zmínku, že posilování navrhovatele samo o sobě brání pouze „levným reorganizacím“, tj. těm, o které se pokouší útočník s malým stakem. Ve skutečnosti může být samotné posilování navrhovatele zneužito většími držiteli staku. Autoři [tohoto příspěvku](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) popisují, jak útočník se 7% staku může strategicky nasadit své hlasy, aby oklamal poctivé validátory, aby stavěli na jeho větvi, a reorganizoval tak poctivý blok. Tento útok byl navržen za předpokladu ideálních podmínek latence, které jsou velmi nepravděpodobné. Šance jsou pro útočníka stále velmi malé a větší stake také znamená větší rizikový kapitál a silnější ekonomickou demotivaci. + +Byl také navržen [vyrovnávací útok specificky zaměřený na pravidlo LMD](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), který byl navržen jako životaschopný navzdory posilování navrhovatele. Útočník nastaví dva konkurenční řetězce tak, že ekvivokuje svůj návrh bloku a každý blok rozšíří asi do poloviny sítě, čímž nastaví přibližnou rovnováhu mezi větvemi. Poté spolupracující validátoři ekvivokují své hlasy a načasují je tak, aby polovina sítě obdržela jejich hlasy pro větev `A` jako první a druhá polovina obdržela jejich hlasy pro větev `B` jako první. Protože pravidlo LMD zahodí druhou atestaci a ponechá si pouze první pro každého validátora, polovina sítě vidí hlasy pro `A` a žádné pro `B`, druhá polovina vidí hlasy pro `B` a žádné pro `A`. Autoři popisují, že pravidlo LMD dává protivníkovi „pozoruhodnou sílu“ k provedení vyrovnávacího útoku. + +Tento LMD vektor útoku byl uzavřen [aktualizací algoritmu volby větve](https://github.com/ethereum/consensus-specs/pull/2845) tak, aby zcela vyloučil ekvivokující validátory z posuzování volby větve. Ekvivokujícím validátorům je také snížen budoucí vliv algoritmem volby větve. To brání vyrovnávacímu útoku popsanému výše a zároveň udržuje odolnost proti lavinovým útokům. + +Další třída útoků, nazývaná [**lavinové útoky**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3), byla popsána ve [studii z března 2022](https://arxiv.org/pdf/2203.01315.pdf). K provedení lavinového útoku potřebuje útočník ovládat několik po sobě jdoucích navrhovatelů bloků. V každém ze slotů pro návrh bloku útočník zadrží svůj blok a sbírá je, dokud poctivý řetězec nedosáhne stejné váhy podstromu jako zadržené bloky. Poté jsou zadržené bloky uvolněny tak, aby maximálně ekvivokovaly. Autoři naznačují, že posilování navrhovatele – primární obrana proti vyrovnávacím a odrazovým útokům – nechrání proti některým variantám lavinového útoku. Autoři však také demonstrovali útok pouze na vysoce idealizované verzi algoritmu volby větve Etherea (použili GHOST bez LMD). + +Lavinový útok je zmírněn částí LMD algoritmu volby větve LMD-GHOST. LMD znamená „latest-message-driven“ (řízený poslední zprávou) a odkazuje na tabulku, kterou si každý validátor udržuje a která obsahuje poslední zprávu obdrženou od ostatních validátorů. Toto pole je aktualizováno pouze v případě, že nová zpráva je z pozdějšího slotu než ta, která je již v tabulce pro konkrétního validátora. V praxi to znamená, že v každém slotu je první přijatá zpráva ta, která je akceptována, a jakékoli další zprávy jsou ekvivokace, které se ignorují. Jinými slovy, konsensuální klienti nepočítají ekvivokace – používají první příchozí zprávu od každého validátora a ekvivokace jsou jednoduše zahozeny, což brání lavinovým útokům. + +Existuje několik dalších potenciálních budoucích vylepšení pravidla volby větve, které by mohly přidat k bezpečnosti poskytované posílením navrhovatele. Jedním je [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), kde atestátoři zmrazí svůj pohled na volbu větve `n` sekund před začátkem slotu a navrhovatel pak pomáhá synchronizovat pohled na řetězec v síti. Dalším potenciálním vylepšením je [finalita jednoho slotu](https://notes.ethereum.org/@vbuterin/single_slot_finality), která chrání proti útokům založeným na časování zpráv finalizací řetězce po jediném slotu. + +#### Zpoždění finality {#finality-delay} + +[Stejná studie](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf), která poprvé popsala levný útok reorganizací jednoho bloku, také popsala útok zpožděním finality (a.k.a „selhání živosti“), který spoléhá na to, že útočník je navrhovatelem bloku na hranici epochy. To je kritické, protože tyto bloky na hranici epochy se stávají kontrolními body, které Casper FFG používá k finalizaci částí řetězce. Útočník jednoduše zadrží svůj blok, dokud dostatek poctivých validátorů nepoužije své FFG hlasy ve prospěch bloku na hranici předchozí epochy jako aktuálního cíle finalizace. Poté uvolní svůj zadržený blok. Atestují svůj blok a zbývající poctiví validátoři také, čímž vytvářejí větve s různými cílovými kontrolními body. Pokud to načasovali správně, zabrání finalitě, protože nebude existovat dvoutřetinová nadpoloviční většina atestující pro žádnou větev. Čím menší je stake, tím přesnější musí být načasování, protože útočník přímo ovládá méně atestací, a tím nižší je pravděpodobnost, že útočník ovládá validátora navrhujícího daný blok na hranici epochy. + +#### Útoky na velkou vzdálenost {#long-range-attacks} + +Existuje také třída útoků specifických pro blockchainy s důkazem podílem, která zahrnuje validátora, jenž se podílel na genesis bloku, udržujícího oddělenou větev blockchainu vedle té poctivé a nakonec přesvědčujícího poctivou sadu validátorů, aby na ni přešla v nějakém vhodném okamžiku mnohem později. Tento typ útoku není na Ethereu možný kvůli finalizačnímu zařízení, které zajišťuje, že se všichni validátoři shodnou na stavu poctivého řetězce v pravidelných intervalech („kontrolních bodech“). Tento jednoduchý mechanismus neutralizuje útočníky na velkou vzdálenost, protože klienti Etherea jednoduše nebudou reorganizovat finalizované bloky. Nové uzly se připojují k síti tak, že najdou důvěryhodný nedávný haš stavu (kontrolní bod „[slabé subjektivity](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/)“) a použijí jej jako pseudo-genesis blok, na kterém staví. To vytváří „důvěryhodnou bránu“ pro nový uzel vstupující do sítě, než si může začít ověřovat informace sám. + +#### Odepření služby {#denial-of-service} + +Mechanismus PoS Etherea vybírá jednoho validátora z celkové sady validátorů jako navrhovatele bloku v každém slotu. To lze vypočítat pomocí veřejně známé funkce a je možné, aby protivník identifikoval dalšího navrhovatele bloku s mírným předstihem před jeho návrhem bloku. Poté může útočník spamovat navrhovatele bloku, aby mu zabránil ve výměně informací s jeho vrstevníky. Zbytku sítě by se zdálo, že navrhovatel bloku byl offline, a slot by jednoduše zůstal prázdný. To by mohla být forma cenzury proti konkrétním validátorům, která by jim bránila v přidávání informací do blockchainu. Implementace voleb jediného tajného lídra (SSLE) nebo voleb nejediného tajného lídra zmírní rizika DoS, protože pouze navrhovatel bloku ví, že byl vybrán, a výběr není znám předem. To ještě není implementováno, ale je to aktivní oblast [výzkumu a vývoje](https://ethresear.ch/t/secret-non-single-leader-election/11789). + +To vše poukazuje na skutečnost, že je velmi obtížné úspěšně zaútočit na Ethereum s malým stakem. Životaschopné útoky, které zde byly popsány, vyžadují idealizovaný algoritmus volby větve, nepravděpodobné podmínky sítě nebo vektory útoku již byly uzavřeny relativně drobnými záplatami klientského softwaru. To samozřejmě nevylučuje možnost existence zero-day zranitelností, ale ukazuje to extrémně vysokou laťku technické zdatnosti, znalostí konsensuální vrstvy a štěstí, které jsou nutné, aby byl útočník s menšinovým stakem účinný. Z pohledu útočníka by jejich nejlepší sázka mohla být nashromáždit co nejvíce etheru a vrátit se vyzbrojeni větším podílem celkového staku. + +### Útočníci používající >= 33 % celkového staku {#attackers-with-33-stake} + +Všechny útoky zmíněné dříve v tomto článku se stávají pravděpodobnějšími, když má útočník více stakovaného etheru k hlasování a více validátorů, kteří mohou být vybráni k navrhování bloků v každém slotu. Škodlivý validátor by se proto mohl zaměřit na ovládnutí co největšího množství stakovaného etheru. + +33 % stakovaného etheru je pro útočníka referenční hodnota, protože s čímkoli větším než tímto množstvím má schopnost zabránit finalizaci řetězce, aniž by musel jemně ovládat akce ostatních validátorů. Mohou jednoduše všichni společně zmizet. Pokud 1/3 nebo více stakovaného etheru škodlivě atestuje nebo neprovádí atestaci, pak nemůže existovat dvoutřetinová nadpoloviční většina a řetězec se nemůže finalizovat. Obranou proti tomu je únik nečinnosti. Únik nečinnosti identifikuje ty validátory, kteří neprovádějí atestaci nebo atestují v rozporu s většinou. Stakovaný ether vlastněný těmito neatestujícími validátory postupně ubývá, dokud nakonec společně nepředstavují méně než 1/3 celkového množství, takže se řetězec může znovu finalizovat. + +Účelem úniku nečinnosti je znovu zprovoznit finalizaci řetězce. Útočník však také ztratí část svého stakovaného etheru. Trvalá nečinnost u validátorů představujících 33 % celkového stakovaného etheru je velmi drahá, i když validátoři nejsou potrestáni (slashed). + +Za předpokladu, že síť Ethereum je asynchronní (tj. dochází ke zpoždění mezi odesláním a přijetím zpráv), útočník ovládající 34 % celkového staku by mohl způsobit dvojí finalitu. Je to proto, že útočník může ekvivokovat, když je vybrán jako producent bloku, a poté dvakrát hlasovat se všemi svými validátory. To vytváří situaci, kdy existuje větev blockchainu, přičemž každá má 34 % stakovaného etheru, který pro ni hlasuje. Každá větev vyžaduje pouze 50 % zbývajících validátorů, aby hlasovali v její prospěch, aby obě větve byly podporovány nadpoloviční většinou, v takovém případě se obě řetězce mohou finalizovat (protože 34 % útočníkových validátorů + polovina zbývajících 66 % = 67 % na každé větvi). Konkurenční bloky by musely být přijaty asi 50 % poctivých validátorů, takže tento útok je životaschopný pouze tehdy, když má útočník určitou míru kontroly nad časováním zpráv šířených po síti, aby mohl nasměrovat polovinu poctivých validátorů na každý řetězec. Útočník by nutně zničil celý svůj stake (34 % z ~10 milionů etherů s dnešní sadou validátorů), aby dosáhl této dvojí finality, protože 34 % jeho validátorů by současně hlasovalo dvakrát – což je trestný čin (slashable) s maximální korelační penalizací. Obranou proti tomuto útoku je velmi vysoká cena zničení 34 % celkového stakovaného etheru. Zotavení z tohoto útoku by vyžadovalo, aby se komunita Etherea koordinovala „mimo pásmo“ a dohodla se, že bude následovat jednu nebo druhou větev a druhou ignorovat. + +### Útočníci používající ~50 % celkového staku {#attackers-with-50-stake} + +S 50 % stakovaného etheru by zlomyslná skupina validátorů teoreticky mohla rozdělit řetězec na dvě stejně velké větve a poté jednoduše použít celý svůj 50% stake k hlasování v rozporu s poctivou sadou validátorů, čímž by udržela obě větve a zabránila finalitě. Únik nečinnosti na obou větvích by nakonec vedl k finalizaci obou řetězců. V tomto okamžiku je jedinou možností vrátit se k sociálnímu zotavení. + +Je velmi nepravděpodobné, že by nepřátelská skupina validátorů mohla trvale ovládat přesně 50 % celkového staku vzhledem k určité fluktuaci počtu poctivých validátorů, latenci sítě atd. – obrovské náklady na provedení takového útoku v kombinaci s nízkou pravděpodobností úspěchu se zdají být silnou demotivací pro racionálního útočníka, zejména když malá dodatečná investice do získání více než 50 % odemkne mnohem více síly. + +S více než 50 % celkového staku by útočník mohl ovládnout algoritmus volby větve. V tomto případě by útočník mohl atestovat s většinovým hlasem, což by mu dalo dostatečnou kontrolu k provádění krátkých reorganizací, aniž by musel klamat poctivé klienty. Poctiví validátoři by následovali, protože jejich algoritmus volby větve by také viděl útočníkem preferovaný řetězec jako nejtěžší, takže by se řetězec mohl finalizovat. To umožňuje útočníkovi cenzurovat určité transakce, provádět krátkodobé reorganizace a extrahovat maximální MEV přeskupováním bloků ve svůj prospěch. Obranou proti tomu je obrovská cena většinového staku (v současnosti téměř 19 miliard USD), který je útočníkem ohrožen, protože sociální vrstva pravděpodobně zasáhne a přijme poctivou menšinovou větev, což dramaticky znehodnotí útočníkův stake. + +### Útočníci používající >=66 % celkového staku {#attackers-with-66-stake} + +Útočník s 66 % nebo více celkového stakovaného etheru může finalizovat svůj preferovaný řetězec, aniž by musel nutit poctivé validátory. Útočník může jednoduše hlasovat pro svou preferovanou větev a poté ji finalizovat, jednoduše proto, že může hlasovat s nepoctivou nadpoloviční většinou. Jako držitel nadpoloviční většiny by útočník vždy ovládal obsah finalizovaných bloků, s mocí utrácet, vracet a znovu utrácet, cenzurovat určité transakce a reorganizovat řetězec podle libosti. Nákupem dalšího etheru k ovládnutí 66 % místo 51 % si útočník v podstatě kupuje schopnost provádět ex post reorganizace a vrácení finality (tj. měnit minulost a ovládat budoucnost). Jedinou skutečnou obranou jsou zde obrovské náklady na 66 % celkového stakovaného etheru a možnost vrátit se k sociální vrstvě a koordinovat přijetí alternativní větve. To si můžeme podrobněji prozkoumat v další části. + +## Lidé: poslední obranná linie {#people-the-last-line-of-defense} + +Pokud se nepoctivým validátorům podaří finalizovat svou preferovanou verzi řetězce, komunita Etherea se dostane do obtížné situace. Kanonický řetězec zahrnuje nepoctivou část zapečenou do své historie, zatímco poctiví validátoři mohou být potrestáni za atestování alternativního (poctivého) řetězce. Všimněte si, že finalizovaný, ale nesprávný řetězec by mohl vzniknout také z chyby ve většinovém klientovi. Nakonec je posledním útočištěm spoléhat se na sociální vrstvu – 0. vrstvu – k vyřešení situace. + +Jednou ze silných stránek konsensu PoS Etherea je, že existuje [řada obranných strategií](https://youtu.be/1m12zgJ42dI?t=1712), které může komunita použít tváří v tvář útoku. Minimální odpovědí by mohlo být nucené opuštění sítě útočníkovými validátory bez jakéhokoli dalšího postihu. Pro opětovný vstup do sítě by se útočník musel zařadit do aktivační fronty, která zajišťuje, že se sada validátorů rozrůstá postupně. Například přidání dostatečného počtu validátorů ke zdvojnásobení množství stakovaného etheru trvá asi 200 dní, což poctivým validátorům efektivně kupuje 200 dní, než se útočník může pokusit o další 51%ní útok. Komunita by se však také mohla rozhodnout potrestat útočníka přísněji, a to zrušením minulých odměn nebo spálením části (až 100 %) jeho stakovaného kapitálu. + +Ať už je útočníkovi uložen jakýkoli trest, komunita se také musí společně rozhodnout, zda je nepoctivý řetězec, přestože je favorizován algoritmem volby větve zakódovaným v klientech Etherea, ve skutečnosti neplatný a zda by komunita měla místo toho stavět na poctivém řetězci. Poctiví validátoři by se mohli kolektivně dohodnout, že budou stavět na komunitou akceptované větvi blockchainu Etherea, která by se například mohla odpojit od kanonického řetězce před začátkem útoku nebo by mohla mít nuceně odstraněné validátory útočníka. Poctiví validátoři by byli motivováni stavět na tomto řetězci, protože by se vyhnuli trestům, které by jim byly uloženy za (oprávněné) neprovedení atestace útočníkova řetězce. Burzy, on-rampy a aplikace postavené na Ethereu by pravděpodobně preferovaly být na poctivém řetězci a následovaly by poctivé validátory na poctivý blockchain. + +To by však byla podstatná výzva pro správu. Někteří uživatelé a validátoři by nepochybně utrpěli v důsledku přechodu zpět na poctivý řetězec, transakce v blocích validovaných po útoku by mohly být potenciálně vráceny, což by narušilo aplikační vrstvu, a jednoduše to podkopává etiku některých uživatelů, kteří mají tendenci věřit, že „kód je zákon“. Burzy a aplikace budou s největší pravděpodobností mít propojené offchain akce s onchain transakcemi, které mohou být nyní vráceny, což spustí kaskádu odvolání a revizí, které by bylo těžké spravedlivě rozplést, zejména pokud byly neoprávněně získané zisky smíchány, uloženy do DeFi nebo jiných derivátů se sekundárními účinky pro poctivé uživatele. Nepochybně někteří uživatelé, možná i institucionální, by již profitovali z nepoctivého řetězce buď díky prozíravosti, nebo náhodě, a mohli by se postavit proti větvi, aby ochránili své zisky. Objevily se výzvy k nácviku reakce komunity na >51%ní útoky, aby bylo možné rychle provést rozumnou koordinovanou mitigaci. Užitečnou diskusi od Vitalika na ethresear.ch najdete [zde](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) a [zde](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363) a na Twitteru [zde](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). Cílem koordinované sociální reakce by mělo být velmi cílené a specifické potrestání útočníka a minimalizace dopadů na ostatní uživatele. + +Správa je již sama o sobě složitým tématem. Řízení nouzové reakce 0. vrstvy na nepoctivý finalizující řetězec by pro komunitu Etherea bylo nepochybně náročné, ale v historii Etherea se to [stalo](/ethereum-forks/#dao-fork-summary) – [dvakrát](/ethereum-forks/#tangerine-whistle)). + +Nicméně je něco docela uspokojivého na tom, že poslední útočiště spočívá v reálném světě. Nakonec, i s touto fenomenální technologickou soustavou nad námi, pokud by se kdy stalo to nejhorší, skuteční lidé by se z toho museli koordinovaně dostat. + +## Shrnutí {#summary} + +Tato stránka prozkoumala některé způsoby, jak by se útočníci mohli pokusit zneužít konsensuální protokol Etherea s důkazem podílem. Byly prozkoumány reorganizace a zpoždění finality pro útočníky s rostoucím podílem celkového stakovaného etheru. Celkově má bohatší útočník větší šanci na úspěch, protože jeho stake se promítá do hlasovací síly, kterou může použít k ovlivnění obsahu budoucích bloků. Při určitých prahových hodnotách stakovaného etheru se síla útočníka zvyšuje: + +33 %: zpoždění finality + +34 %: zpoždění finality, dvojí finalita + +51 %: zpoždění finality, dvojí finalita, cenzura, kontrola nad budoucností blockchainu + +66 %: zpoždění finality, dvojí finalita, cenzura, kontrola nad budoucností i minulostí blockchainu + +Existuje také řada sofistikovanějších útoků, které vyžadují malé množství stakovaného etheru, ale spoléhají na velmi sofistikovaného útočníka, který má jemnou kontrolu nad časováním zpráv, aby ovlivnil poctivou sadu validátorů ve svůj prospěch. + +Celkově je navzdory těmto potenciálním vektorům útoku riziko úspěšného útoku nízké, rozhodně nižší než u ekvivalentů s důkazem prací. Je to kvůli obrovským nákladům na stakovaný ether, který je ohrožen útočníkem, jenž se snaží přemoci poctivé validátory svou hlasovací silou. Zabudovaná vrstva pobídek „cukru a biče“ chrání před většinou zločinného jednání, zejména u útočníků s nízkým stakem. Jemnější odrazové a vyrovnávací útoky také pravděpodobně neuspějí, protože reálné podmínky sítě činí jemnou kontrolu doručování zpráv konkrétním podmnožinám validátorů velmi obtížně dosažitelnou a týmy klientů rychle uzavřely známé vektory odrazových, vyrovnávacích a lavinových útoků jednoduchými záplatami. + +Útoky s 34 %, 51 % nebo 66 % by pravděpodobně vyžadovaly sociální koordinaci mimo pásmo k vyřešení. I když by to pro komunitu pravděpodobně bylo bolestivé, schopnost komunity reagovat mimo pásmo je pro útočníka silnou demotivací. Sociální vrstva Etherea je konečnou pojistkou – technicky úspěšný útok by stále mohl být neutralizován, pokud by se komunita dohodla na přijetí poctivé větve. Dojde k závodu mezi útočníkem a komunitou Etherea – miliardy dolarů utracené za 66% útok by pravděpodobně byly zničeny úspěšným sociálním koordinačním útokem, pokud by byl proveden dostatečně rychle, a útočníkovi by zůstaly těžké pytle nelikvidního stakovaného etheru na známém nepoctivém řetězci ignorovaném komunitou Etherea. Pravděpodobnost, že by to pro útočníka bylo ziskové, je dostatečně nízká na to, aby to bylo účinným odstrašujícím prostředkem. Proto je investice do udržování soudržné sociální vrstvy s pevně sladěnými hodnotami tak důležitá. + +## Další čtení {#further-reading} + +- [Podrobnější verze této stránky](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Vitalik o finalitě vypořádání](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Studie o LMD GHOST](https://arxiv.org/abs/2003.03052) +- [Práce na Casper-FFG](https://arxiv.org/abs/1710.09437) +- [Práce na Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Specifikace konsensu pro posílení váhy navrhovatele](https://github.com/ethereum/consensus-specs/pull/2730) +- [Odrazové útoky na ethresear.ch](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [Výzkum SSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..971e0b98e02 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: Atestace +description: "Popis atestací na Ethereu s důkazem podílem." +lang: cs +--- + +Očekává se, že validátor během každé epochy vytvoří, podepíše a odvysílá atestaci. Tato stránka popisuje, jak tyto atestace vypadají a jak jsou zpracovávány a předávány mezi konsensuálními klienty. + +## Co je atestace? {#what-is-an-attestation} + +Každou [epochu](/glossary/#epoch) (6,4 minuty) validátor navrhuje síti atestaci. Atestace se týká konkrétního slotu v epoše. Účelem atestace je hlasovat ve prospěch pohledu validátora na řetězec, zejména pro nejnovější potvrzený blok a první blok v aktuální epoše (známé jako kontrolní body `source` a `target`). Tyto informace od všech zúčastněných validátorů se zkombinují, což síti umožňuje dosáhnout konsensu o stavu blockchainu. + +Atestace obsahuje následující komponenty: + +- `aggregation_bits`: bitový seznam validátorů, kde pozice odpovídá indexu validátora v jeho výboru; hodnota (0/1) udává, zda validátor podepsal `data` (tzn. zda je aktivní a souhlasí s navrhovatelem bloku) +- `data`: podrobnosti týkající se atestace, jak je definováno níže +- `signature`: podpis BLS, který agreguje podpisy jednotlivých validátorů + +Prvním úkolem atestujícího validátora je sestavit `data`. `data` obsahuje následující informace: + +- `slot`: Číslo slotu, na který se atestace vztahuje +- `index`: Číslo, které identifikuje, do kterého výboru validátor v daném slotu patří +- `beacon_block_root`: Kořenový haš bloku, který validátor vidí v čele řetězce (výsledek použití algoritmu pro výběr větve) +- `source`: Část hlasování o finalitě, která udává, co validátoři považují za nejnovější potvrzený blok +- `target`: Část hlasování o finalitě, která udává, co validátoři považují za první blok v aktuální epoše + +Jakmile jsou `data` sestavena, může validátor otočit bit v `aggregation_bits` odpovídající jeho vlastnímu indexu validátora z 0 na 1, aby ukázal, že se zúčastnil. + +Nakonec validátor podepíše atestaci a odvysílá ji do sítě. + +### Agregovaná atestace {#aggregated-attestation} + +S předáváním těchto dat po síti pro každého validátora je spojena značná režie. Proto jsou atestace od jednotlivých validátorů agregovány v podsítích, než jsou odvysílány do širší sítě. To zahrnuje agregaci podpisů tak, aby atestace, která je odvysílána, obsahovala konsensuální `data` a jediný podpis vytvořený spojením podpisů všech validátorů, kteří s těmito `daty` souhlasí. To lze zkontrolovat pomocí `aggregation_bits`, protože to poskytuje index každého validátora v jeho výboru (jehož ID je uvedeno v `data`), který lze použít k dotazování na jednotlivé podpisy. + +V každé epoše je v každé podsíti vybráno 16 validátorů, kteří se stanou `agregátory`. Agregátoři shromažďují všechny atestace, o kterých se doslechnou v gossip síti a které mají ekvivalentní `data` jako jejich vlastní. Odesílatel každé shodné atestace je zaznamenán v `aggregation_bits`. Agregátoři poté odvysílají agregát atestací do širší sítě. + +Když je validátor vybrán jako navrhovatel bloku, zabalí agregované atestace z podsítí až do posledního slotu do nového bloku. + +### Životní cyklus zahrnutí atestace {#attestation-inclusion-lifecycle} + +1. Generování +2. Šíření +3. Agregace +4. Šíření +5. Zahrnutí + +Životní cyklus atestace je znázorněn na schématu níže: + +![životní cyklus atestace](./attestation_schematic.png) + +## Odměny {#rewards} + +Validátoři jsou za odesílání atestací odměňováni. Odměna za atestaci závisí na příznacích účasti (zdroj, cíl a hlava), základní odměně a míře účasti. + +Každý z příznaků účasti může být buď pravdivý, nebo nepravdivý, v závislosti na odeslané atestaci a jejím zpoždění zahrnutí. + +Nejlepší scénář nastává, když jsou všechny tři příznaky pravdivé, v takovém případě by validátor získal (za každý správný příznak): + +`odměna += základní odměna * váha příznaku * míra atestace příznaku / 64` + +Míra atestace příznaku se měří pomocí součtu efektivních zůstatků všech atestujících validátorů pro daný příznak v porovnání s celkovým aktivním efektivním zůstatkem. + +### Základní odměna {#base-reward} + +Základní odměna se vypočítá podle počtu atestujících validátorů a jejich efektivních uzamčených zůstatků etheru: + +`základní odměna = efektivní zůstatek validátora x 2^6 / SQRT(Efektivní zůstatek všech aktivních validátorů)` + +#### Zpoždění zahrnutí {#inclusion-delay} + +V době, kdy validátoři hlasovali o čele řetězce (`blok n`), `blok n+1` ještě nebyl navržen. Atestace se proto přirozeně zařazují **o jeden blok později**, takže všechny atestace, které hlasovaly o tom, že `blok n` je čelo řetězce, se zařadily do `bloku n+1` a **zpoždění zahrnutí** je 1. Pokud se zpoždění zahrnutí zdvojnásobí na dva sloty, odměna za atestaci se sníží na polovinu, protože pro výpočet odměny za atestaci se základní odměna násobí převrácenou hodnotou zpoždění zahrnutí. + +### Scénáře atestací {#attestation-scenarios} + +#### Chybějící hlasující validátor {#missing-voting-validator} + +Validátoři mají na odeslání své atestace maximálně 1 epochu. Pokud byla atestace v epoše 0 zmeškána, mohou ji odeslat se zpožděním zahrnutí v epoše 1. + +#### Chybějící agregátor {#missing-aggregator} + +V každé epoše je celkem 16 agregátorů. Kromě toho se náhodní validátoři přihlásí k odběru **dvou podsítí na 256 epoch** a slouží jako záloha pro případ, že by agregátoři chyběli. + +#### Chybějící navrhovatel bloku {#missing-block-proposer} + +Všimněte si, že v některých případech se šťastný agregátor může stát i navrhovatelem bloku. Pokud atestace nebyla zahrnuta, protože navrhovatel bloku chyběl, další navrhovatel bloku by agregovanou atestaci vyzvedl a zahrnul ji do dalšího bloku. Nicméně, **zpoždění zahrnutí** se zvýší o jedna. + +## Další čtení {#further-reading} + +- [Atestace v komentované specifikaci konsensu od Vitalika](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Atestace na eth2book.info](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_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/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..c429abf2a32 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "Návrh bloku" +description: "Vysvětlení, jak se navrhují bloky v síti Ethereum s mechanismem konsensu důkaz podílem." +lang: cs +--- + +Bloky jsou základní jednotky blockchainu. Bloky jsou samostatné jednotky informací, které se předávají mezi uzly, odsouhlasují se a přidávají se do databáze každého uzlu. Tato stránka vysvětluje, jak se vytvářejí. + +## Předpoklady {#prerequisites} + +Navrhování bloků je součástí protokolu důkaz podílem. Pro lepší pochopení této stránky doporučujeme přečíst si o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) a [architektuře bloků](/developers/docs/blocks/). + +## Kdo vytváří bloky? {#who-produces-blocks} + +Bloky navrhují účty validátorů. Účty validátorů spravují operátoři uzlů, kteří provozují software validátorů jako součást svých exekučních a konsensuálních klientů a kteří vložili alespoň 32 ETH do smlouvy o vkladu. Každý validátor je však za navržení bloku zodpovědný jen příležitostně. Ethereum měří čas ve slotech a epochách. Každý slot trvá dvanáct sekund a 32 slotů (6,4 minuty) tvoří jednu epochu. Každý slot je příležitostí přidat do sítě Ethereum nový blok. + +### Náhodný výběr {#random-selection} + +V každém slotu je pseudonáhodně vybrán jeden validátor, který navrhne blok. V blockchainu neexistuje skutečná náhodnost, protože kdyby každý uzel generoval skutečně náhodná čísla, nemohly by dospět ke konsensu. Cílem je naopak učinit proces výběru validátorů nepředvídatelným. Náhodnosti se v síti Ethereum dosahuje pomocí algoritmu RANDAO, který smíchá haš od navrhovatele bloku se seedem, který se aktualizuje s každým blokem. Tato hodnota se používá k výběru konkrétního validátora z celkové sady validátorů. Výběr validátora je stanoven dvě epochy předem, aby se zabránilo určitým druhům manipulace se seedem. + +Ačkoli validátoři přispívají do RANDAO v každém slotu, globální hodnota RANDAO se aktualizuje pouze jednou za epochu. Pro výpočet indexu dalšího navrhovatele bloku se hodnota RANDAO smíchá s číslem slotu, aby v každém slotu vznikla jedinečná hodnota. Pravděpodobnost výběru jednotlivého validátora není pouze `1/N` (kde `N` = celkový počet aktivních validátorů). Místo toho je vážena efektivním zůstatkem ETH každého validátora. Maximální efektivní zůstatek je 32 ETH (to znamená, že `zůstatek < 32 ETH` vede k nižší váze než `zůstatek == 32 ETH`, ale `zůstatek > 32 ETH` nevede k vyšší váze než `zůstatek == 32 ETH`). + +V každém slotu je vybrán pouze jeden navrhovatel bloku. Za normálních podmínek vytvoří a vydá jeden tvůrce bloku jeden blok ve svém vyhrazeném slotu. Vytvoření dvou bloků pro stejný slot je přestupek, za který hrozí trest (tzv. slashing), často známý jako „ekvivokace“. + +## Jak se blok vytváří? {#how-is-a-block-created} + +Očekává se, že navrhovatel bloku bude vysílat podepsaný beacon blok, který navazuje na nejnovější hlavu řetězce podle pohledu jeho vlastního lokálně spuštěného algoritmu pro výběr větve. Algoritmus pro výběr větve použije všechny atestace ve frontě z předchozího slotu a poté najde blok s největší kumulovanou váhou atestací ve své historii. Tento blok je rodičem nového bloku vytvořeného navrhovatelem. + +Navrhovatel bloku vytváří blok shromažďováním dat z vlastní lokální databáze a pohledu na řetězec. Obsah bloku je uveden v úryvku níže: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +Pole `randao_reveal` obsahuje ověřitelnou náhodnou hodnotu, kterou navrhovatel bloku vytvoří podepsáním čísla aktuální epochy. `eth1_data` je hlasování o pohledu navrhovatele bloku na smlouvu o vkladu, včetně kořene Merkle trie vkladů a celkového počtu vkladů, který umožňuje ověřování nových vkladů. `graffiti` je volitelné pole, které lze použít k přidání zprávy do bloku. `proposer_slashings` a `attester_slashings` jsou pole, která obsahují důkaz, že se někteří validátoři podle pohledu navrhovatele na řetězec dopustili přestupků, za které hrozí trest. `deposits` je seznam nových vkladů validátorů, o kterých ví navrhovatel bloku, a `voluntary_exits` je seznam validátorů, kteří chtějí odejít a o kterých se navrhovatel bloku doslechl v gossip síti na konsensuální vrstvě. `sync_aggregate` je vektor, který ukazuje, kteří validátoři byli dříve přiřazeni k synchronizačnímu výboru (podmnožina validátorů, kteří poskytují data lehkým klientům) a podíleli se na podepisování dat. + +`execution_payload` umožňuje předávání informací o transakcích mezi exekučními a konsensuálními klienty. `execution_payload` je blok exekučních dat, který je vnořen do beacon bloku. Pole uvnitř `execution_payload` odrážejí strukturu bloku popsanou ve Žluté knize Etherea, s tím rozdílem, že neobsahují ommery a místo `difficulty` existuje `prev_randao`. Exekuční klient má přístup k lokálnímu poolu transakcí, o kterých se dozvěděl ve své vlastní gossip síti. Tyto transakce se spouštějí lokálně, aby se vygeneroval aktualizovaný stavový strom (trie), známý jako post-state. Transakce jsou zahrnuty v `execution_payload` jako seznam nazvaný `transactions` a post-state je uveden v poli `state-root`. + +Všechna tato data jsou shromážděna v beacon bloku, podepsána a vysílána peerům navrhovatele bloku, kteří je dále šíří svým peerům atd. + +Přečtěte si více o [anatomii bloků](/developers/docs/blocks). + +## Co se stane s blokem? {#what-happens-to-blocks} + +Blok je přidán do lokální databáze navrhovatele bloku a vysílán peerům prostřednictvím gossip sítě konsensuální vrstvy. Když validátor obdrží blok, ověří data v něm, včetně kontroly, zda má blok správného rodiče, odpovídá správnému slotu, zda je index navrhovatele očekávaný, zda je odhalení RANDAO platné a zda navrhovatel nebyl potrestán (slashingem). `execution_payload` se rozbalí a exekuční klient validátora znovu provede transakce v seznamu, aby zkontroloval navrhovanou změnu stavu. Za předpokladu, že blok projde všemi těmito kontrolami, každý validátor přidá blok do svého vlastního kanonického řetězce. Proces se pak znovu spustí v dalším slotu. + +## Odměny za blok {#block-rewards} + +Navrhovatel bloku dostává za svou práci odměnu. Existuje `base_reward` (základní odměna) vypočtená jako funkce počtu aktivních validátorů a jejich efektivních zůstatků. Navrhovatel bloku pak obdrží zlomek `base_reward` za každou platnou atestaci obsaženou v bloku; čím více validátorů blok dosvědčí, tím větší je odměna navrhovatele bloku. Existuje také odměna za nahlášení validátorů, kteří by měli být potrestáni (slashingem), která se rovná `1/512 * efektivní zůstatek` za každého potrestaného validátora. + +[Více o odměnách a trestech](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## Další čtení {#further-reading} + +- [Úvod do bloků](/developers/docs/blocks/) +- [Úvod do důkazu podílem](/developers/docs/consensus-mechanisms/pos/) +- [Specifikace konsensu Etherea](https://github.com/ethereum/consensus-specs) +- [Úvod do Gasperu](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Vylepšování Etherea](https://eth2book.info/) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..b3c5a0666f8 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "Často kladené otázky" +description: "Často kladené otázky ohledně Etherea s důkazem podílem." +lang: cs +--- + +## Co je to důkaz podílem {#what-is-proof-of-stake} + +Důkaz podílem je třída algoritmu, která může poskytnout zabezpečení blockchainům tím, že zajistí, že útočníci, kteří jednají nečestně, přijdou o hodnotná aktiva. Systémy s důkazem podílem vyžadují, aby sada validátorů zpřístupnila nějaký majetek, který může být zničen, pokud se validátor prokazatelně chová nečestně. Ethereum používá mechanismus důkazu podílem k zabezpečení blockchainu. + +## Jak si stojí důkaz podílem v porovnání s důkazem prací? {#comparison-to-proof-of-work} + +Jak důkaz prací, tak důkaz podílem jsou mechanismy, které ekonomicky odrazují škodlivé aktéry od spamování nebo podvodů v síti. V obou případech uzly, které se aktivně účastní konsensu, vkládají "do sítě" nějaké aktivum, o které přijdou, pokud se budou chovat nesprávně. + +V případě důkazu prací je tímto aktivem energie. Uzel, známý jako těžař, spouští algoritmus, jehož cílem je vypočítat hodnotu rychleji než jakýkoli jiný uzel. Nejrychlejší uzel má právo navrhnout blok do řetězce. Aby mohl těžař změnit historii řetězce nebo ovládnout navrhování bloků, musel by mít tolik výpočetního výkonu, aby vždy vyhrál závod. Je to neúměrně drahé a obtížně proveditelné, což chrání řetězec před útoky. Energie potřebná k "těžbě" pomocí důkazu prací je reálné aktivum, za které těžaři platí. + +Důkaz podílem vyžaduje, aby uzly, známé jako validátoři, explicitně odeslaly kryptoaktivum do chytrého kontraktu. Pokud se validátor chová nesprávně, může být toto kryptoaktivum zničeno, protože svá aktiva "stakují" přímo do řetězce, nikoli nepřímo prostřednictvím výdajů na energii. + +Důkaz prací je mnohem energeticky náročnější, protože při procesu těžby se spotřebovává elektřina. Na druhou stranu důkaz podílem vyžaduje jen velmi malé množství energie – validátoři Etherea mohou dokonce běžet na zařízení s nízkou spotřebou, jako je Raspberry Pi. Mechanismus důkazu podílem Etherea je považován za bezpečnější než důkaz prací, protože náklady na útok jsou vyšší a důsledky pro útočníka jsou závažnější. + +Důkaz prací versus důkaz podílem je kontroverzní téma. [Blog Vitalika Buterina](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) a debata mezi Justinem Drakem a Lyn Aldenovou poskytují dobré shrnutí argumentů. + + + +## Je důkaz podílem energeticky účinný? {#is-pos-energy-efficient} + +Ano. Uzly v síti s důkazem podílem spotřebovávají nepatrné množství energie. Studie třetí strany dospěla k závěru, že celá síť Ethereum s důkazem podílem spotřebuje přibližně 0,0026 TWh/rok – což je asi 13 000krát méně než hraní her v samotných USA. + +[Více o spotřebě energie Etherea](/energy-consumption/). + +## Je důkaz podílem bezpečný? {#is-pos-secure} + +Důkaz podílem Etherea je velmi bezpečný. Mechanismus byl osm let důkladně zkoumán, vyvíjen a testován, než byl spuštěn do ostrého provozu. Bezpečnostní záruky se liší od blockchainů s důkazem prací. V důkazu podílem mohou být škodliví validátoři aktivně potrestáni ("slashed") a vyloučeni ze sady validátorů, což je stojí značné množství ETH. V případě důkazu prací může útočník opakovat svůj útok, dokud má dostatečný hašovací výkon. Je také nákladnější provádět ekvivalentní útoky na Ethereum s důkazem podílem než na Ethereum s důkazem prací. K ovlivnění živosti řetězce je zapotřebí alespoň 33 % z celkového stakovaného etheru v síti (kromě případů velmi sofistikovaných útoků s extrémně nízkou pravděpodobností úspěchu). K ovládání obsahu budoucích bloků je zapotřebí alespoň 51 % z celkového stakovaného ETH a k přepsání historie je zapotřebí více než 66 % z celkového staku. Protokol Etherea by zničil tato aktiva ve scénářích 33% nebo 51% útoku a prostřednictvím společenského konsensu ve scénáři 66% útoku. + +- [Více o obraně Etherea s důkazem podílem před útočníky](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Více o návrhu důkazu podílem](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## Je díky důkazu podílem Ethereum levnější? {#does-pos-make-ethereum-cheaper} + +Ne. Cena za odeslání transakce (poplatek za gas) je určena dynamickým trhem s poplatky, který se zvyšuje s rostoucí poptávkou v síti. Mechanismus konsensu to přímo neovlivňuje. + +[Více o gasu](/developers/docs/gas). + +## Co jsou to uzly, klienti a validátoři? {#what-are-nodes-clients-and-validators} + +Uzly jsou počítače připojené k síti Ethereum. Klienti jsou software, který na nich běží a který z počítače dělá uzel. Existují dva typy klientů: exekuční klienti a konsensuální klienti. K vytvoření uzlu jsou zapotřebí oba. Validátor je volitelný doplněk ke konsensuálnímu klientovi, který uzlu umožňuje účastnit se konsensu důkazu podílem. To znamená vytvářet a navrhovat bloky, když je uzel vybrán, a potvrzovat bloky, o kterých se dozví v síti. Pro provozování validátoru musí operátor uzlu vložit 32 ETH do depozitního kontraktu. + +- [Více o uzlech a klientech](/developers/docs/nodes-and-clients) +- [Více o stakování](/staking) + +## Je důkaz podílem nová myšlenka? {#is-pos-new} + +Ne. Uživatel na BitcoinTalku [navrhl základní myšlenku důkazu podílem](https://bitcointalk.org/index.php?topic=27787.0) jako vylepšení Bitcoinu v roce 2011. Trvalo jedenáct let, než byl připraven k implementaci na hlavní síti Ethereum. Některé jiné řetězce implementovaly důkaz podílem dříve než Ethereum, ale ne specifický mechanismus Etherea (známý jako Gasper). + +## Čím je důkaz podílem na Ethereu výjimečný? {#why-is-ethereum-pos-special} + +Mechanismus důkazu podílem na Ethereu je svým designem unikátní. Nebyl to první mechanismus důkazu podílem, který byl navržen a implementován, ale je nejrobustnější. Tento mechanismus důkazu podílem je známý jako "Casper". Casper definuje, jak jsou vybíráni validátoři pro navrhování bloků, jak a kdy se provádějí atestace, jak se atestace počítají, odměny a tresty pro validátory, podmínky pro slashing, bezpečnostní mechanismy jako únik neaktivity a podmínky pro "finalitu". Finalita je podmínka, že aby byl blok považován za trvalou součást kanonického řetězce, musí pro něj hlasovat alespoň 66 % z celkového stakovaného ETH v síti. Výzkumníci vyvinuli Casper speciálně pro Ethereum a Ethereum je první a jediný blockchain, který ho implementoval. + +Kromě Casperu používá důkaz podílem Etherea algoritmus pro výběr větve nazvaný LMD-GHOST. To je nutné pro případ, že nastane situace, kdy pro stejný slot existují dva bloky. Tím vzniknou dvě větve blockchainu. LMD-GHOST vybere tu, která má největší "váhu" atestací. Váha je počet atestací vážený efektivním zůstatkem validátorů. LMD-GHOST je unikátní pro Ethereum. + +Kombinace Casper a LMD_GHOST je známá jako Gasper. + +[Více o Gasperu](/developers/docs/consensus-mechanisms/pos/gasper/) + +## Co je to slashing? {#what-is-slashing} + +Slashing je termín pro zničení části staku validátora a jeho vyloučení ze sítě. Množství ETH ztracených při slashingu se škáluje s počtem „slashed“ validátorů – to znamená, že tajně spolupracující validátoři jsou potrestáni přísněji než jednotlivci. + +[Více o slashingu](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## Proč validátoři potřebují 32 ETH? {#why-32-eth} + +Validátoři musí stakovat ETH, aby měli co ztratit, pokud se budou chovat nesprávně. Důvodem, proč musí stakovat právě 32 ETH, je umožnit provoz uzlů na skromném hardwaru. Pokud by bylo minimum ETH na validátora nižší, počet validátorů a tím i počet zpráv, které musí být zpracovány v každém slotu, by se zvýšil, což by znamenalo, že k provozu uzlu by byl zapotřebí výkonnější hardware. + +## Jak jsou vybíráni validátoři? {#how-are-validators-selected} + +Jeden validátor je pseudo-náhodně vybrán, aby navrhl blok v každém slotu pomocí algoritmu zvaného RANDAO, který mísí haš od navrhovatele bloku se seedem, který se aktualizuje s každým blokem. Tato hodnota se používá k výběru konkrétního validátora z celkové sady validátorů. Výběr validátora je stanoven s předstihem dvou epoch. + +[Více o výběru validátorů](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## Co je to „stake grinding“? {#what-is-stake-grinding} + +„Stake grinding“ je kategorie útoku na sítě s důkazem podílem, kde se útočník snaží ovlivnit algoritmus výběru validátorů ve prospěch svých vlastních validátorů. Útoky typu „stake grinding“ na RANDAO vyžadují asi polovinu celkového stakovaného ETH. + +[Více o „stake grinding“](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## Co je to sociální slashing? {#what-is-social-slashing} + +Sociální slashing je schopnost komunity koordinovat větev blockchainu v reakci na útok. Umožňuje komunitě zotavit se poté, co útočník finalizuje nečestný řetězec. Sociální slashing lze také použít proti útokům cenzury. + +- [Více o sociálním slashingu](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Vitalik Buterin o sociálním slashingu](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## Hrozí mi slashing? {#will-i-get-slashed} + +Jako validátorovi vám hrozí slashing jen velmi těžko, pokud se záměrně nezapojíte do škodlivého chování. Slashing se provádí pouze ve velmi specifických scénářích, kdy validátoři navrhnou více bloků pro stejný slot nebo si protiřečí svými atestacemi – je velmi nepravděpodobné, že by k tomu došlo náhodou. + +[Více o podmínkách pro slashing](https://eth2book.info/altair/part2/incentives/slashing) + +## Co je to problém „nothing-at-stake“? {#what-is-nothing-at-stake-problem} + +Problém „nothing-at-stake“ je koncepční problém některých mechanismů důkazu podílem, kde existují pouze odměny a žádné tresty. Pokud není nic v sázce, pragmatický validátor je stejně ochoten potvrzovat jakoukoli, nebo dokonce více větví blockchainu, protože to zvyšuje jeho odměny. Ethereum tento problém řeší pomocí podmínek finality a slashingu, aby zajistilo jeden kanonický řetězec. + +[Více o problému „nothing-at-stake“](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## Co je to algoritmus pro výběr větve? {#what-is-a-fork-choice-algorithm} + +Algoritmus pro výběr větve implementuje pravidla, která určují, který řetězec je ten kanonický. Za optimálních podmínek není pravidlo pro výběr větve potřeba, protože na každý slot připadá pouze jeden navrhovatel bloku a na výběr je pouze jeden blok. Občas se však stane, že více bloků pro stejný slot nebo pozdě doručené informace vedou k více možnostem, jak jsou bloky poblíž hlavy řetězce uspořádány. V těchto případech musí všichni klienti implementovat některá pravidla identicky, aby bylo zajištěno, že všichni vyberou správnou sekvenci bloků. Algoritmus pro výběr větve tato pravidla kóduje. + +Algoritmus Etherea pro výběr větve se nazývá LMD-GHOST. Vybírá větev s největší váhou atestací, což znamená tu, pro kterou hlasovala většina stakovaného ETH. + +[Více o LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Co je to finalita v důkazu podílem? {#what-is-finality} + +Finalita v důkazu podílem je záruka, že daný blok je trvalou součástí kanonického řetězce a nelze jej vrátit zpět, pokud nedojde k selhání konsensu, při kterém útočník spálí 33 % z celkového stakovaného etheru. Jedná se o "kryptoekonomickou" finalitu, na rozdíl od "pravděpodobnostní finality", která je relevantní pro blockchainy s důkazem prací. Při pravděpodobnostní finalitě neexistují pro bloky žádné explicitní finalizované/nefinalizované stavy – jednoduše se stává stále méně pravděpodobným, že by blok mohl být z řetězce odstraněn, čím je starší, a uživatelé si sami určují, kdy jsou dostatečně přesvědčeni, že je blok "bezpečný". Při kryptoekonomické finalitě musí pro páry kontrolních bloků (checkpoint) hlasovat 66 % stakovaného etheru. Pokud je tato podmínka splněna, bloky mezi těmito kontrolními body jsou explicitně "finalizovány". + +[Více o finalitě](/developers/docs/consensus-mechanisms/pos/#finality) + +## Co je to "slabá subjektivita"? {#what-is-weak-subjectivity} + +Slabá subjektivita je vlastnost sítí s důkazem podílem, kde se sociální informace používají k potvrzení aktuálního stavu blockchainu. Novým uzlům nebo uzlům, které se znovu připojují k síti po dlouhé době offline, lze poskytnout nedávný stav, takže uzel může okamžitě zjistit, zda je na správném řetězci. Tyto stavy jsou známé jako "kontrolní body slabé subjektivity" a lze je získat od jiných operátorů uzlů mimo pásmo (out-of-band), z prohlížečů bloků nebo z několika veřejných koncových bodů. + +[Více o slabé subjektivitě](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## Je důkaz podílem odolný proti cenzuře? {#is-pos-censorship-resistant} + +Odolnost proti cenzuře je v současné době obtížné prokázat. Na rozdíl od důkazu prací však důkaz podílem nabízí možnost koordinovat slashingy k potrestání cenzurujících validátorů. Připravují se změny protokolu, které oddělují tvůrce bloků od navrhovatelů bloků a implementují seznamy transakcí, které tvůrci musí do každého bloku zahrnout. Tento návrh je známý jako oddělení navrhovatele a tvůrce (proposer-builder separation) a pomáhá zabránit validátorům v cenzurování transakcí. + +[Více o oddělení navrhovatele a tvůrce](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Může být systém důkazu podílem Etherea napaden 51% útokem? {#pos-51-attack} + +Ano. Důkaz podílem je zranitelný vůči 51% útokům, stejně jako důkaz prací. Místo toho, aby útočník potřeboval 51 % hašovacího výkonu sítě, potřebuje 51 % celkového stakovaného ETH. Útočník, který nashromáždí 51 % celkového staku, získá kontrolu nad algoritmem pro výběr větve. To útočníkovi umožňuje cenzurovat určité transakce, provádět reorganizace krátkého dosahu a extrahovat MEV přeskupováním bloků ve svůj prospěch. + +[Více o útocích na důkaz podílem](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## Co je to sociální koordinace a proč je potřebná? {#what-is-social-coordination} + +Sociální koordinace je poslední obrannou linií Etherea, která by umožnila obnovit poctivý řetězec z útoku, který finalizoval nepoctivé bloky. V tomto případě by se komunita Etherea musela koordinovat "mimo pásmo" (out-of-band) a dohodnout se na použití poctivé menšinové větve, přičemž by v procesu provedla slashing validátorů útočníka. To by vyžadovalo, aby i aplikace a burzy uznaly poctivou větev. + +[Přečtěte si více o sociální koordinaci](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## Bohatnou v důkazu podílem bohatí? {#do-rich-get-richer} + +Čím více ETH někdo stakuje, tím více validátorů může provozovat a tím více odměn může získat. Odměny se škálují lineárně s množstvím stakovaného ETH a každý dostává stejné procentuální zhodnocení. Důkaz prací obohacuje bohaté více než důkaz podílem, protože bohatší těžaři, kteří nakupují hardware ve velkém, těží z úspor z rozsahu, což znamená, že vztah mezi bohatstvím a odměnou je nelineární. + +## Je důkaz podílem centralizovanější než důkaz prací? {#is-pos-decentralized} + +Ne, důkaz prací má tendenci k centralizaci, protože náklady na těžbu rostou a vytlačují jednotlivce, pak malé společnosti a tak dále. Současným problémem důkazu podílem je vliv derivátů likvidního stakování (LSD). Jedná se o tokeny reprezentující ETH stakované nějakým poskytovatelem, které může kdokoli směnit na sekundárních trzích, aniž by skutečné ETH bylo odemčeno (unstaked). LSD umožňují uživatelům stakovat s méně než 32 ETH, ale také vytvářejí riziko centralizace, kde několik velkých organizací může nakonec ovládat velkou část staku. [samostatné stakování](/staking/solo) je pro Ethereum nejlepší volbou. + +[Více o centralizaci staku v LSD](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Proč mohu stakovat pouze ETH? {#why-can-i-only-stake-eth} + +ETH je vlastní měna na platformě Ethereum. Je nezbytné mít jednotnou měnu, ve které jsou denominovány všechny staky, a to jak pro účtování efektivních zůstatků pro vážení hlasů, tak pro bezpečnost. Samotné ETH je základní součástí Etherea, nikoli chytrý kontrakt. Začlenění jiných měn by výrazně zvýšilo složitost a snížilo bezpečnost stakování. + +## Je Ethereum jediný blockchain s důkazem podílem? {#is-ethereum-the-only-pos-blockchain} + +Ne, existuje několik blockchainů s důkazem podílem. Žádný není identický s Ethereem; mechanismus důkazu podílem Etherea je unikátní. + +## Co je to The Merge? {#what-is-the-merge} + +The Merge byl okamžik, kdy Ethereum vypnulo svůj mechanismus konsensu založený na důkazu prací a zapnulo svůj mechanismus konsensu založený na důkazu podílem. The Merge proběhlo 15. září 2022. + +[Více o The Merge](/roadmap/merge) + +## Co je to živost a bezpečnost? {#what-are-liveness-and-safety} + +Živost a bezpečnost jsou dva základní bezpečnostní aspekty blockchainu. Živost je dostupnost finalizujícího řetězce. Pokud řetězec přestane finalizovat nebo k němu uživatelé nemohou snadno přistupovat, jedná se o selhání živosti. Extrémně vysoké náklady na přístup by také mohly být považovány za selhání živosti. Bezpečnost se týká toho, jak obtížné je zaútočit na řetězec – tj. finalizovat konfliktní kontrolní body (checkpointy). + +[Přečtěte si více v dokumentu o Casperu](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..4fa8c39b71a --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Vysvětlení mechanismu důkazu podílem Gasper." +lang: cs +--- + +Gasper je kombinací Casper the Friendly Finality Gadget (Casper-FFG) a algoritmu pro výběr větve LMD-GHOST. Tyto komponenty společně tvoří mechanismus konsenzu, který zabezpečuje Ethereum na bázi důkazu podílem. Casper je mechanismus, který povyšuje určité bloky na „finalizované“, takže noví účastníci sítě si mohou být jisti, že synchronizují kanonický řetězec. Algoritmus pro výběr větve využívá nahromaděné hlasy, aby zajistil, že uzly mohou snadno vybrat tu správnou větev, když v blockchainu vzniknou větve. + +**Upozornění:** Původní definice Casper-FFG byla pro zařazení do systému Gasper mírně aktualizována. Na této stránce se budeme zabývat aktualizovanou verzí. + +## Předpoklady + +Pro pochopení tohoto materiálu je nutné si přečíst úvodní stránku o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). + +## Role systému Gasper {#role-of-gasper} + +Gasper funguje na blockchainu s důkazem podílem, kde uzly poskytují ether jako bezpečnostní zálohu, která může být zničena, pokud jsou nečinné nebo nečestné při navrhování nebo validaci bloků. Gasper je mechanismus, který definuje, jak jsou validátoři odměňováni a trestáni, jak se rozhodují, které bloky přijmout a které odmítnout a na které větvi blockchainu stavět. + +## Co je to finalita? {#what-is-finality} + +Finalita je vlastnost určitých bloků, která znamená, že nemohou být vráceny zpět, pokud nedošlo ke kritickému selhání konsenzu a útočník nezničil alespoň 1/3 celkového uzamčeného etheru. Finalizované bloky lze považovat za informace, kterými si je blockchain jistý. Aby mohl být blok finalizován, musí projít dvoukrokovým procesem vylepšení: + +1. Dvě třetiny z celkového uzamčeného etheru musí hlasovat pro zahrnutí tohoto bloku do kanonického řetězce. Tato podmínka povýší blok na „justifikovaný“. Je nepravděpodobné, že by justifikované bloky byly vráceny zpět, ale za určitých podmínek se to může stát. +2. Když je další blok justifikován nad justifikovaným blokem, je povýšen na „finalizovaný“. Finalizace bloku je závazek zahrnout daný blok do kanonického řetězce. Nelze jej vrátit zpět, pokud útočník nezničí miliony etheru (miliardy USD). + +Tato vylepšení bloků se nedějí v každém slotu. Místo toho lze justifikovat a finalizovat pouze bloky na hranicích epoch. Tyto bloky jsou známé jako „checkpointy“. Vylepšení se týká dvojic checkpointů. Mezi dvěma po sobě jdoucími checkpointy musí existovat „propojení nadpoloviční většinou“ (tzn. dvě třetiny z celkového uzamčeného etheru hlasují, že checkpoint B je správným potomkem checkpointu A), aby se starší checkpoint povýšil na finalizovaný a novější blok na justifikovaný. + +Protože finalita vyžaduje dvoutřetinovou shodu na tom, že blok je kanonický, útočník nemůže vytvořit alternativní finalizovaný řetězec, aniž by: + +1. Vlastnil nebo manipuloval se dvěma třetinami z celkového uzamčeného etheru. +2. Zničil alespoň jednu třetinu z celkového uzamčeného etheru. + +První podmínka vyplývá z toho, že k finalizaci řetězce jsou zapotřebí dvě třetiny uzamčeného etheru. Druhá podmínka vyplývá z toho, že pokud dvě třetiny z celkového podílu hlasovaly pro obě větve, pak jedna třetina musela hlasovat pro obě. Dvojí hlasování je podmínka pro slashing, která by byla maximálně potrestána a jedna třetina celkového podílu by byla zničena. K květnu 2022 to vyžaduje, aby útočník spálil ether v hodnotě zhruba 10 miliard dolarů. Algoritmus, který v systému Gasper justifikuje a finalizuje bloky, je mírně upravenou formou [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf). + +### Pobídky a slashing {#incentives-and-slashing} + +Validátoři jsou odměňováni za poctivé navrhování a validaci bloků. Ether je odměňován a přidáván k jejich podílu. Na druhou stranu validátoři, kteří jsou nepřítomní a nekonají, když jsou k tomu vyzváni, o tyto odměny přicházejí a někdy ztratí malou část svého stávajícího podílu. Sankce za offline stav jsou však malé a ve většině případů se rovnají nákladům ušlé příležitosti ze ztracených odměn. Některé akce validátorů je však velmi obtížné provést náhodou a značí nějaký zlovolný úmysl, jako je navrhování více bloků pro stejný slot, atestování více bloků pro stejný slot nebo protiřečení si s předchozími hlasy o checkpointech. Jedná se o chování, které je „trestatelné slashingem“ a které je trestáno přísněji – slashing má za následek zničení části podílu validátora a jeho odstranění ze sítě validátorů. Tento proces trvá 36 dní. První den je udělena počáteční pokuta až do výše 1 ETH. Poté ether slasheovaného validátora během doby odchodu pomalu odtéká, ale 18. den obdrží „korelační pokutu“, která je vyšší, když je ve stejnou dobu slasheováno více validátorů. Maximální trest je celý podíl. Tyto odměny a tresty jsou navrženy tak, aby motivovaly poctivé validátory a odrazovaly od útoků na síť. + +### Únik z neaktivity {#inactivity-leak} + +Kromě zabezpečení poskytuje Gasper také „pravděpodobnou živost“. Je to podmínka, že dokud dvě třetiny z celkového uzamčeného etheru hlasují poctivě a dodržují protokol, řetězec bude schopen finalizace bez ohledu na jakoukoli jinou aktivitu (jako jsou útoky, problémy s latencí nebo slashing). Jinými slovy, jedna třetina celkového uzamčeného etheru musí být nějakým způsobem kompromitována, aby se zabránilo finalizaci řetězce. V systému Gasper existuje další obranná linie proti selhání živosti, známá jako „únik z neaktivity“. Tento mechanismus se aktivuje, když se řetězci nepodařilo finalizovat déle než čtyři epochy. Validátorům, kteří aktivně neatestují většinový řetězec, se postupně odčerpává jejich podíl, dokud většina znovu nezíská dvoutřetinový podíl z celkového objemu, což zajišťuje, že selhání živosti jsou pouze dočasná. + +### Výběr větve {#fork-choice} + +Původní definice Casper-FFG zahrnovala algoritmus pro výběr větve, který zavedl pravidlo: `sledujte řetězec obsahující justifikovaný checkpoint, který má největší výšku`, kde výška je definována jako největší vzdálenost od genesis bloku. V systému Gasper je původní pravidlo pro výběr větve zastaralé a nahrazeno sofistikovanějším algoritmem zvaným LMD-GHOST. Je důležité si uvědomit, že za normálních podmínek není pravidlo pro výběr větve nutné – pro každý slot existuje jediný navrhovatel bloku a poctiví validátoři jej atestují. Algoritmus pro výběr větve je vyžadován pouze v případech velké asynchronicity sítě nebo když se nepoctivý navrhovatel bloku dopustil ekvivokace. Když však tyto případy nastanou, algoritmus pro výběr větve je kritickou obranou, která zajišťuje správný řetězec. + +LMD-GHOST je zkratka pro „latest message-driven greedy heaviest observed sub-tree“ (nejnovější zprávou řízený chamtivý nejtěžší pozorovaný podstrom). Jedná se o odborný způsob, jak definovat algoritmus, který jako kanonickou větev vybere tu s největší nahromaděnou váhou atestací (chamtivý nejtěžší podstrom) a který v případě, že je od validátora přijato více zpráv, bere v úvahu pouze tu poslední (řízený nejnovější zprávou). Před přidáním nejtěžšího bloku do svého kanonického řetězce každý validátor posoudí každý blok pomocí tohoto pravidla. + +## Další čtení {#further-reading} + +- [Gasper: Kombinace GHOST a Casper](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..aa90c757c2c --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: Proof-of-stake (PoS) +description: "Vysvětlení konsensuálního protokolu důkaz podílem a jeho role v platformě Ethereum." +lang: cs +--- + +Důkaz podílem (PoS) je základem [mechanismu konsensu](/developers/docs/consensus-mechanisms/) sítě Ethereum. Ethereum přešlo v roce 2022 na mechanismus důkazu podílem, protože je bezpečnější, méně energeticky náročný a lepší pro implementaci nových řešení škálování ve srovnání s předchozí architekturou [důkazu prací](/developers/docs/consensus-mechanisms/pow). + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky vám doporučujeme si nejprve přečíst o [mechanismech konsensu](/developers/docs/consensus-mechanisms/). + +## Co je proof of stake (PoS)? {#what-is-pos} + +Důkaz podílem je způsob, jak prokázat, že validátoři vložili do sítě něco hodnotného, co může být zničeno, pokud jednají nečestně. V mechanismu důkazu podílem Etherea validátoři explicitně stakují kapitál ve formě ETH do chytrého kontraktu na Ethereu. Validátor je pak zodpovědný za kontrolu, zda jsou nové bloky šířené po síti platné, a občas za vytváření a šíření nových bloků. Pokud se pokusí síť podvést (například navržením více bloků, když by měli poslat jeden, nebo zasláním konfliktních atestací), může být část nebo celé jejich stakované ETH zničeno. + +## Validátoři {#validators} + +Aby se uživatel mohl stát validátorem, musí vložit 32 ETH do depozitního kontraktu a spustit tři samostatné softwarové programy: exekučního klienta, konsensuálního klienta a klienta validátora. Po vložení ETH se uživatel zařadí do aktivační fronty, která omezuje rychlost připojování nových validátorů do sítě. Po aktivaci validátoři dostávají nové bloky od peerů v síti Ethereum. Transakce doručené v bloku jsou znovu provedeny, aby se zkontrolovalo, že navrhované změny stavu Etherea jsou platné, a zkontroluje se podpis bloku. Validátor pak pošle hlas (nazývaný atestace) ve prospěch daného bloku po celé síti. + +Zatímco v případě důkazu prací je časování bloků určeno obtížností těžby, v případě důkazu podílem je tempo pevně dané. Čas v síti Ethereum s důkazem podílem je rozdělen na sloty (12 sekund) a epochy (32 slotů). V každém slotu je náhodně vybrán jeden validátor, který bude navrhovatelem bloku. Tento validátor je zodpovědný za vytvoření nového bloku a jeho odeslání ostatním uzlům v síti. V každém slotu je také náhodně vybrán výbor validátorů, jejichž hlasy se použijí k určení platnosti navrhovaného bloku. Rozdělení sady validátorů do výborů je důležité pro udržení zvládnutelné zátěže sítě. Výbory rozdělují sadu validátorů tak, aby každý aktivní validátor atestoval v každé epoše, ale ne v každém slotu. + +## Jak se transakce provádí v síti Ethereum s PoS {#transaction-execution-ethereum-pos} + +Následující text poskytuje kompletní vysvětlení toho, jak se transakce provádí v síti Ethereum s mechanismem důkazu podílem. + +1. Uživatel vytvoří a podepíše [transakci](/developers/docs/transactions/) svým soukromým klíčem. To obvykle zajišťuje peněženka nebo knihovna, jako je [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) atd., ale na pozadí uživatel odesílá požadavek na uzel pomocí Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/). Uživatel definuje množství gasu, které je ochoten zaplatit jako spropitné validátorovi, aby ho motivoval k zahrnutí transakce do bloku. [Spropitné](/developers/docs/gas/#priority-fee) se vyplácí validátorovi, zatímco [základní poplatek](/developers/docs/gas/#base-fee) je spálen. +2. Transakce je odeslána [exekučnímu klientovi](/developers/docs/nodes-and-clients/#execution-client) sítě Ethereum, který ověří její platnost. To znamená zajistit, aby odesílatel měl dostatek ETH k provedení transakce a aby ji podepsal správným klíčem. +3. Pokud je transakce platná, exekuční klient ji přidá do svého lokálního mempoolu (seznamu nevyřízených transakcí) a také ji rozešle ostatním uzlům prostřednictvím gossip sítě exekuční vrstvy. Když se o transakci dozví další uzly, přidají ji také do svého lokálního mempoolu. Pokročilí uživatelé se mohou zdržet vysílání své transakce a místo toho ji přeposlat specializovaným tvůrcům bloků, jako je [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview). To jim umožňuje organizovat transakce v nadcházejících blocích pro maximální zisk ([MEV](/developers/docs/mev/#mev-extraction)). +4. Jeden z validátorských uzlů v síti je navrhovatelem bloku pro aktuální slot, který byl předtím pseudo-náhodně vybrán pomocí RANDAO. Tento uzel je zodpovědný za sestavení a vysílání dalšího bloku, který má být přidán do blockchainu Etherea, a za aktualizaci globálního stavu. Uzel se skládá ze tří částí: exekučního klienta, konsensuálního klienta a klienta validátora. Exekuční klient seskupuje transakce z lokálního mempoolu do "exekuční datové části" a lokálně je provádí, aby vygeneroval změnu stavu. Tato informace se předává konsensuálnímu klientovi, kde je exekuční datová část zabalena jako součást "beacon bloku", který také obsahuje informace o odměnách, penále, slashingu, atestacích atd., které síti umožňují dohodnout se na sekvenci bloků na čele řetězce. Komunikace mezi exekučním a konsensuálním klientem je podrobněji popsána v části [Propojení konsensuálního a exekučního klienta](/developers/docs/networking-layer/#connecting-clients). +5. Ostatní uzly přijímají nový beacon blok v gossip síti konsensuální vrstvy. Předají jej svému exekučnímu klientovi, kde jsou transakce znovu lokálně provedeny, aby se zajistilo, že navrhovaná změna stavu je platná. Klient validátora pak atestuje, že blok je platný a je logickým dalším blokem v jeho pohledu na řetězec (což znamená, že navazuje na řetězec s největší váhou atestací, jak je definováno v [pravidlech výběru větve](/developers/docs/consensus-mechanisms/pos/#fork-choice)). Blok je přidán do lokální databáze v každém uzlu, který ho atestuje. +6. Transakce může být považována za "finalizovanou", pokud se stala součástí řetězce s "nadpolovičním spojením" mezi dvěma kontrolními body. Kontrolní body se vyskytují na začátku každé epochy a existují proto, aby se zohlednila skutečnost, že v každém slotu atestuje pouze podmnožina aktivních validátorů, ale v každé epoše atestují všichni aktivní validátoři. Proto pouze mezi epochami může být prokázáno ‚nadpoloviční spojení‘ (to je místo, kde se 66 % z celkového stakovaného ETH v síti shodne na dvou kontrolních bodech). + +Více podrobností o finalitě naleznete níže. + +## Konečnost {#finality} + +Transakce má v distribuovaných sítích "finalitu", pokud je součástí bloku, který nelze změnit, aniž by bylo spáleno velké množství ETH. V síti Ethereum s důkazem podílem je to řešeno pomocí "kontrolních" bloků. První blok v každé epoše je kontrolním bodem. Validátoři hlasují pro dvojice kontrolních bodů, které považují za platné. Pokud dvojice kontrolních bodů získá hlasy představující alespoň dvě třetiny z celkového stakovaného ETH, jsou kontrolní body vylepšeny. Novější z těchto dvou (cíl) se stane "opodstatněným". Dřívější z nich je již opodstatněný, protože byl "cílem" v předchozí epoše. Nyní je vylepšen na "finalizovaný". Tento proces vylepšování kontrolních bodů zajišťuje **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)**. Casper-FFG je nástroj pro finalitu bloku v rámci konsensu. Jakmile je blok finalizován, nelze jej vrátit ani změnit bez většinového slashingu stakerů, což ho činí ekonomicky neživotaschopným. + +Aby mohl útočník vrátit finalizovaný blok, musel by se zavázat ke ztrátě nejméně jedné třetiny celkové zásoby stakovaného ETH. Přesný důvod je vysvětlen v tomto [blogovém příspěvku nadace Ethereum](https://blog.ethereum.org/2016/05/09/on-settlement-finality/). Protože finalita vyžaduje dvoutřetinovou většinu, útočník by mohl zabránit síti v dosažení finality hlasováním s jednou třetinou celkového podílu. Existuje mechanismus na obranu proti tomu: [únik z nečinnosti](https://eth2book.info/bellatrix/part2/incentives/inactivity). Tento mechanismus se aktivuje vždy, když se řetězec nepodaří finalizovat po dobu delší než čtyři epochy. Únik z nečinnosti odčerpává stakované ETH od validátorů, kteří hlasují proti většině, což umožňuje většině znovu získat dvoutřetinovou většinu a finalizovat řetězec. + +## Kryptoekonomická bezpečnost {#crypto-economic-security} + +Provozování validátora je závazek. Od validátora se očekává, že bude udržovat dostatečný hardware a konektivitu, aby se mohl účastnit validace a navrhování bloků. Na oplátku je validátor placen v ETH (jeho stakovaný zůstatek se zvyšuje). Na druhou stranu účast v roli validátora také otevírá nové možnosti pro uživatele, jak zaútočit na síť za účelem osobního zisku nebo sabotáže. Aby se tomu zabránilo, validátoři přicházejí o odměny v ETH, pokud se neúčastní, když jsou vyzváni, a jejich stávající podíl může být zničen, pokud se chovají nečestně. Za nečestné lze považovat dvě hlavní chování: navrhování více bloků v jednom slotu (ekvivokace) a předkládání rozporuplných atestací. + +Množství seknutého ETH závisí na tom, kolik validátorů je také seknuto přibližně ve stejnou dobu. Toto je známé jako ["korelační pokuta"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) a může být malá (~1% podílu pro jednoho samostatně seknutého validátora) nebo může vést ke zničení 100% podílu validátora (událost hromadného slashingu). Je uložena v polovině období nuceného odchodu, které začíná okamžitou pokutou (až 1 ETH) 1. den, korelační pokutou 18. den a nakonec vyloučením ze sítě 36. den. Dostávají každý den malé pokuty za atestace, protože jsou přítomni v síti, ale nepředkládají hlasy. To vše znamená, že koordinovaný útok by byl pro útočníka velmi nákladný. + +## Výběr větve {#fork-choice} + +Když síť funguje optimálně a poctivě, na čele řetězce je vždy jen jeden nový blok a všichni validátoři ho atestují. Je však možné, že validátoři mají různé pohledy na čelo řetězce kvůli latenci sítě nebo protože navrhovatel bloku ekvivokoval. Proto konsensuální klienti vyžadují algoritmus, který rozhodne, kterému dát přednost. Algoritmus používaný v síti Ethereum s důkazem podílem se nazývá [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) a funguje tak, že identifikuje větev, která má ve své historii největší váhu atestací. + +## Důkaz podílem a bezpečnost {#pos-and-security} + +Hrozba [51% útoku](https://www.investopedia.com/terms/1/51-attack.asp) stále existuje u důkazu podílem, stejně jako u důkazu prací, ale pro útočníky je ještě riskantnější. Útočník by potřeboval 51 % stakovaného ETH. Poté by mohli použít své vlastní atestace, aby zajistili, že jejich preferovaná větev bude ta s nejvíce nahromaděnými atestacemi. „Váha“ nahromaděných atestací je to, co konsensuální klienti používají k určení správného řetězce, takže tento útočník by byl schopen učinit svou větev kanonickou. Silnou stránkou důkazu podílem oproti důkazu prací je však to, že komunita má flexibilitu při zahájení protiútoku. Poctiví validátoři by se například mohli rozhodnout pokračovat v budování menšinového řetězce a ignorovat útočníkovu větev a zároveň povzbuzovat aplikace, burzy a pooly, aby udělaly totéž. Mohli by se také rozhodnout násilně odstranit útočníka ze sítě a zničit jeho stakované ETH. Jedná se o silnou ekonomickou obranu proti 51% útoku. + +Kromě 51% útoků se mohou záškodníci pokusit i o jiné typy škodlivých aktivit, jako jsou: + +- útoky na velkou vzdálenost (ačkoli nástroj finality tento vektor útoku neutralizuje) +- krátkodobé „reorganizace“ (ačkoli toto zmírňuje podpora navrhovatele a termíny pro atestace) +- odrážecí a vyvažovací útoky (také zmírněné podporou navrhovatele a tyto útoky byly stejně prokázány pouze za idealizovaných síťových podmínek) +- lavinové útoky (neutralizované pravidlem algoritmu pro výběr větve, který zvažuje pouze nejnovější zprávu) + +Celkově se ukázalo, že důkaz podílem, jak je implementován na Ethereu, je ekonomicky bezpečnější než důkaz prací. + +## Výhody a nevýhody {#pros-and-cons} + +| Plusy | Minusy | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | +| Staking usnadňuje jednotlivcům účast na zabezpečení sítě a podporuje decentralizaci. validátorský uzel lze provozovat na běžném notebooku. Staking pooly umožňují uživatelům stakovat bez nutnosti mít 32 ETH. | Důkaz podílem je mladší a méně prověřený v praxi ve srovnání s důkazem prací. | +| Staking je více decentralizovaný. Úspory z rozsahu se neuplatňují stejným způsobem jako při těžbě s PoW. | Důkaz podílem je složitější na implementaci než důkaz prací. | +| Důkaz podílem nabízí větší kryptoekonomickou bezpečnost než důkaz prací. | Uživatelé musí spustit tři softwarové programy, aby se mohli podílet na důkazu podílem Etherea. | +| K motivaci účastníků sítě je zapotřebí menší vydávání nových ETH. | | + +### Srovnání s důkazem prací {#comparison-to-proof-of-work} + +Ethereum původně používalo důkaz prací, ale v září 2022 přešlo na důkaz podílem. PoS nabízí několik výhod oproti PoW, jako jsou: + +- lepší energetická účinnost – není třeba spotřebovávat velké množství energie na výpočty v rámci důkazu prací +- nižší bariéry vstupu, snížené hardwarové nároky – není potřeba elitní hardware, abyste měli šanci vytvářet nové bloky +- snížené riziko centralizace – důkaz podílem by měl vést k většímu počtu uzlů zabezpečujících síť +- kvůli nízké energetické náročnosti je k motivaci účasti zapotřebí menší vydávání ETH +- ekonomické pokuty za špatné chování činí útoky ve stylu 51 % pro útočníka nákladnějšími ve srovnání s důkazem prací +- komunita se může uchýlit k sociální obnově poctivého řetězce, pokud by 51% útok překonal kryptoekonomickou obranu. + +## Další čtení {#further-reading} + +- [Často kladené otázky k důkazu podílem](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [Co je důkaz podílem](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Co je důkaz podílem a proč na něm záleží](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [Proč důkaz podílem (listopad 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [Důkaz podílem: Jak jsem se naučil milovat slabou subjektivitu](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [Útok a obrana Etherea s důkazem podílem](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Filozofie návrhu důkazu podílem](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [Video: Vitalik Buterin vysvětluje důkaz podílem Lexi Fridmanovi](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## Související témata {#related-topics} + +- [Důkaz prací](/developers/docs/consensus-mechanisms/pow/) +- [Důkaz autoritou](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..fb02fd40bb2 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "Klíče v proof-of-stake Ethereu" +description: "Vysvětlení klíčů používaných v mechanismu konsensu proof-of-stake v Ethereu" +lang: cs +--- + +Ethereum zabezpečuje majetek uživatelů pomocí kryptografie s veřejným a soukromým klíčem. Veřejný klíč se používá jako základ pro adresu Etherea – to znamená, že je viditelný pro širokou veřejnost a používá se jako jedinečný identifikátor. Soukromý (neboli „tajný“) klíč by měl být přístupný pouze majiteli účtu. Soukromý klíč se používá k „podepisování“ transakcí a dat, aby kryptografie mohla prokázat, že držitel schvaluje určitou akci konkrétního soukromého klíče. + +Klíče Etherea se generují pomocí [kryptografie na bázi eliptických křivek](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography). + +Když však Ethereum přešlo z [důkazu prací](/developers/docs/consensus-mechanisms/pow) na [důkaz podílem](/developers/docs/consensus-mechanisms/pos), byl do Etherea přidán nový typ klíče. Původní klíče stále fungují úplně stejně jako dříve – u klíčů založených na eliptických křivkách, které zabezpečují účty, nedošlo k žádným změnám. Uživatelé však potřebovali nový typ klíče pro účast v mechanismu proof-of-stake prostřednictvím stakingu ETH a provozování validátorů. Tato potřeba vznikla z problémů se škálovatelností spojených s velkým množstvím zpráv předávaných mezi velkým počtem validátorů, což vyžadovalo kryptografickou metodu, kterou by bylo možné snadno agregovat, aby se snížilo množství komunikace potřebné k tomu, aby síť dosáhla konsensu. + +Tento nový typ klíče používá schéma podpisu [**Boneh-Lynn-Shacham (BLS)**](https://wikipedia.org/wiki/BLS_digital_signature). BLS umožňuje velmi efektivní agregaci podpisů, ale také umožňuje zpětné inženýrství agregovaných jednotlivých klíčů validátorů a je ideální pro správu akcí mezi validátory. + +## Dva typy klíčů validátora {#two-types-of-keys} + +Před přechodem na proof-of-stake měli uživatelé Etherea pro přístup ke svým prostředkům pouze jediný soukromý klíč založený na eliptických křivkách. Se zavedením proof-of-stake potřebovali uživatelé, kteří chtěli být solo stakery, také **klíč validátora** a **klíč pro výběr**. + +### Klíč validátora {#validator-key} + +Podpisový klíč validátora se skládá ze dvou prvků: + +- **Soukromý** klíč validátora +- **Veřejný** klíč validátora + +Účelem soukromého klíče validátora je podepisovat on-chain operace, jako jsou návrhy bloků a atestace. Z tohoto důvodu musí být tyto klíče uloženy v horké peněžence. + +Tato flexibilita má tu výhodu, že umožňuje velmi rychlý přesun podpisových klíčů validátora z jednoho zařízení na druhé, avšak v případě jejich ztráty nebo odcizení může zloděj několika způsoby **jednat se zlým úmyslem**: + +- Způsobit slashing validátora tím, že: + - Jako navrhovatel podepíše dva různé beacon bloky pro stejný slot + - Jako atestátor podepíše atestaci, která "obklopuje" jinou + - Jako atestátor podepíše dvě různé atestace se stejným cílem +- Vynutí si dobrovolný odchod, čímž validátor přestane se stakingem a majitel klíče pro výběr získá přístup k jeho zůstatku ETH + +**Veřejný klíč validátora** je zahrnut v transakčních datech, když uživatel vkládá ETH do smlouvy o vkladu pro staking. Toto se nazývá _data vkladu_ a umožňuje to Ethereu identifikovat validátora. + +### Pověření pro výběr {#withdrawal-credentials} + +Každý validátor má vlastnost známou jako _pověření pro výběr_. První bajt tohoto 32bajtového pole identifikuje typ účtu: `0x00` představuje původní BLS pověření (před upgradem Shapella, bez možnosti výběru), `0x01` představuje starší pověření, která odkazují na exekuční adresu, a `0x02` představuje moderní typ složeného pověření. + +Validátoři s BLS klíči `0x00` musí tato pověření aktualizovat, aby odkazovala na exekuční adresu, a aktivovat tak platby z přebytku zůstatku nebo plný výběr ze stakingu. To lze provést buď poskytnutím exekuční adresy v datech vkladu během počátečního generování klíčů, _NEBO_ pozdějším použitím klíče pro výběr k podepsání a odvysílání zprávy `BLSToExecutionChange`. + +[Více o pověřeních pro výběr validátora](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### Klíč pro výběr {#withdrawal-key} + +Klíč pro výběr bude vyžadován k aktualizaci pověření pro výběr, aby odkazovala na exekuční adresu, pokud nebyla nastavena během počátečního vkladu. To umožní zahájení zpracování plateb z přebytku zůstatku a také umožní uživatelům plně vybrat jejich stakovaná ETH. + +Stejně jako klíče validátora se i klíče pro výběr skládají ze dvou složek: + +- **Soukromý** klíč pro výběr +- **Veřejný** klíč pro výběr + +Ztráta tohoto klíče před aktualizací pověření pro výběr na typ `0x01` znamená ztrátu přístupu k zůstatku validátora. Validátor může stále podepisovat atestace a bloky, protože tyto akce vyžadují soukromý klíč validátora, avšak v případě ztráty klíčů pro výběr je motivace malá nebo žádná. + +Oddělení klíčů validátora od klíčů účtu Ethereum umožňuje jednomu uživateli provozovat více validátorů. + +![schéma klíče validátora](validator-key-schematic.png) + +**Poznámka**: Ukončení povinností stakingu a výběr zůstatku validátora v současné době vyžaduje podepsání [zprávy o dobrovolném odchodu (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) klíčem validátora. [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) je však návrh, který v budoucnu umožní uživateli spustit odchod validátora a výběr jeho zůstatku podepsáním zpráv o odchodu klíčem pro výběr. Tím se sníží předpoklady důvěry, protože stakerům, kteří delegují ETH [poskytovatelům stakingu jako služby](/staking/saas/#what-is-staking-as-a-service), umožní mít své prostředky stále pod kontrolou. + +## Odvození klíčů z bezpečnostní fráze {#deriving-keys-from-seed} + +Pokud by každých 32 stakovaných ETH vyžadovalo novou sadu 2 zcela nezávislých klíčů, správa klíčů by se rychle stala nepraktickou, zejména pro uživatele provozující více validátorů. Místo toho lze odvodit více klíčů validátora z jediného společného tajemství a uložení tohoto jediného tajemství umožňuje přístup k více klíčům validátora. + +[Mnemotechnické pomůcky](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) a cesty jsou prominentními prvky, se kterými se uživatelé často setkávají, když [přistupují](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) ke svým peněženkám. Mnemotechnická pomůcka je sekvence slov, která funguje jako počáteční seed pro soukromý klíč. V kombinaci s dalšími daty generuje mnemotechnická pomůcka haš známý jako „hlavní klíč“. To si lze představit jako kořen stromu. Větve z tohoto kořene lze poté odvodit pomocí hierarchické cesty, takže podřízené uzly mohou existovat jako kombinace haše jejich nadřazeného uzlu a jejich indexu ve stromě. Přečtěte si o standardech [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) a [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) pro generování klíčů na základě mnemotechnických pomůcek. + +Tyto cesty mají následující strukturu, která bude známá uživatelům, kteří interagovali s hardwarovými peněženkami: + +``` +m/44'/60'/0'/0` +``` + +Lomítka v této cestě oddělují složky soukromého klíče následovně: + +``` +hlavní_klíč / účel / typ_mince / účet / změna / index_adresy +``` + +Tato logika umožňuje uživatelům připojit co nejvíce validátorů k jediné **mnemotechnické frázi**, protože kořen stromu může být společný a odlišení může probíhat na úrovni větví. Uživatel může z mnemotechnické fráze **odvodit libovolný počet klíčů**. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +Každá větev je oddělena znakem `/`, takže `m/2` znamená začít od hlavního klíče a sledovat větev 2. V níže uvedeném schématu se jediná mnemotechnická fráze používá k uložení tří klíčů pro výběr, z nichž každý má dva přidružené validátory. + +![logika klíčů validátora](multiple-keys.png) + +## Další čtení {#further-reading} + +- [Příspěvek na blogu Nadace Ethereum od Carla Beekhuizena](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 Generování klíčů BLS12-381](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: Odchody spouštěné exekuční vrstvou](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [Správa klíčů ve velkém měřítku](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..0a76fb31791 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Důkaz podílem vs. důkaz prací" +description: "Srovnání mechanismu konsensu Etherea založeného na důkazu podílem a důkazu prací" +lang: cs +--- + +Když bylo Ethereum spuštěno, důkaz podílem ještě potřeboval hodně výzkumu a vývoje, než mu mohlo být svěřeno zabezpečení Etherea. Důkaz prací byl jednodušší mechanismus, který již byl prověřen Bitcoinem, což znamenalo, že ho hlavní vývojáři mohli ihned implementovat a spustit tak Ethereum. Trvalo dalších osm let, než se důkaz podílem vyvinul do bodu, kdy mohl být implementován. + +Tato stránka vysvětluje důvody přechodu Etherea z důkazu prací na důkaz podílem a s tím spojené kompromisy. + +## Bezpečnost {#security} + +Výzkumníci Etherea považují důkaz podílem za bezpečnější než důkaz prací. Byl však implementován teprve nedávno na skutečné hlavní síti Etherea a je méně časem prověřený než důkaz prací. Následující části pojednávají o výhodách a nevýhodách bezpečnostního modelu důkazu podílem ve srovnání s důkazem prací. + +### Náklady na útok {#cost-to-attack} + +V systému důkazu podílem musí validátoři uzamknout („stakovat“) alespoň 32 ETH v chytrém kontraktu. Ethereum může zničit uzamčený ether, aby potrestalo validátory, kteří se chovají nesprávně. Aby se dosáhlo konsensu, musí pro určitou sadu bloků hlasovat alespoň 66 % z celkového uzamčeného etheru. Bloky, pro které hlasovalo >=66 % vkladu, se stávají „finalizovanými“, což znamená, že je nelze odstranit ani přeorganizovat. + +Útok na síť může znamenat zabránění finalizaci řetězce nebo zajištění určitého uspořádání bloků v kanonickém řetězci, které nějakým způsobem prospívá útočníkovi. To vyžaduje, aby útočník odklonil cestu poctivého konsensu buď nahromaděním velkého množství etheru a přímým hlasováním s ním, nebo tím, že přiměje poctivé validátory, aby hlasovali určitým způsobem. Kromě sofistikovaných, málo pravděpodobných útoků, které klamou poctivé validátory, jsou náklady na útok na Ethereum náklady na vklad, který musí útočník nahromadit, aby ovlivnil konsensus ve svůj prospěch. + +Nejnižší náklady na útok jsou >33 % z celkového vkladu. Útočník, který drží >33 % celkového vkladu, může způsobit zpoždění finality tím, že se jednoduše odpojí. Pro síť se jedná o relativně malý problém, protože existuje mechanismus známý jako „únik z nečinnosti“ (inactivity leak), který přesouvá vklady od offline validátorů, dokud online většina nepředstavuje 66 % vkladu a nemůže řetězec znovu finalizovat. Je také teoreticky možné, aby útočník s více než 33 % celkového vkladu způsobil dvojí finalitu tím, že vytvoří dva bloky místo jednoho, když je požádán, aby byl producentem bloku, a poté provede dvojité hlasování se všemi svými validátory. Každá větev vyžaduje pouze 50 % zbývajících poctivých validátorů, aby viděli každý blok jako první, takže pokud se jim podaří správně načasovat své zprávy, mohou být schopni finalizovat obě větve. Pravděpodobnost úspěchu je nízká, ale pokud by se útočníkovi podařilo způsobit dvojitou finalitu, komunita Etherea by se musela rozhodnout následovat jednu větev, v takovém případě by u validátorů útočníka na druhé větvi nutně došlo ke slashingu. + +S >33 % z celkového vkladu má útočník šanci mít menší (zpoždění finality) nebo závažnější (dvojitá finalita) dopad na síť Etherea. S více než 14 000 000 ETH uzamčenými v síti a reprezentativní cenou 1000 $/ETH jsou minimální náklady na provedení těchto útoků `1000 x 14 000 000 x 0.33 = 4 620 000 000 $`. Útočník by o tyto peníze přišel prostřednictvím slashingu a byl by vyloučen ze sítě. Aby mohl zaútočit znovu, musel by (znovu) nashromáždit >33 % vkladu a (znovu) jej spálit. Každý pokus o útok na síť by stál více než 4,6 miliardy dolarů (při ceně 1 000 $/ETH a 14 milionech uzamčených ETH). Útočník je také vyloučen ze sítě, když dojde ke slashingu, a musí se zařadit do aktivační fronty, aby se mohl znovu připojit. To znamená, že rychlost opakovaného útoku je omezena nejen rychlostí, jakou může útočník nashromáždit >33 % z celkového vkladu, ale také časem, který je zapotřebí k zapojení všech jeho validátorů do sítě. Pokaždé, když útočník zaútočí, výrazně zchudne a zbytek komunity zbohatne díky výslednému šoku v nabídce. + +Jiné útoky, jako jsou 51% útoky nebo zvrácení finality s 66 % celkového vkladu, vyžadují podstatně více ETH a jsou pro útočníka mnohem nákladnější. + +Porovnejte to s důkazem prací. Náklady na zahájení útoku na Ethereum s důkazem prací byly náklady na trvalé vlastnictví >50 % celkového hashratu sítě. To se rovnalo nákladům na hardware a provoz dostatečného výpočetního výkonu, aby bylo možné trvale překonávat ostatní těžaře při výpočtu řešení pro důkaz prací. Ethereum se většinou těžilo pomocí GPU, nikoli ASIC, což udržovalo nízké náklady (ačkoli kdyby Ethereum zůstalo u důkazu prací, těžba pomocí ASIC by se mohla stát populárnější). Protivník by musel nakoupit spoustu hardwaru a zaplatit za elektřinu k jeho provozu, aby zaútočil na síť Ethereum s důkazem prací, ale celkové náklady by byly nižší než náklady potřebné k nashromáždění dostatečného množství ETH k zahájení útoku. 51% útok je na důkazu prací přibližně [20krát levnější](https://youtu.be/1m12zgJ42dI?t=1562) než na důkazu podílem. Pokud by byl útok odhalen a v řetězci by došlo k hard forku, aby se odstranily změny útočníka, mohl by útočník opakovaně použít stejný hardware k útoku na novou větev. + +### Složitost {#complexity} + +Důkaz podílem je mnohem složitější než důkaz prací. To by mohlo být plus pro důkaz prací, protože je těžší náhodně zavést chyby nebo nezamýšlené efekty do jednodušších protokolů. Složitost však byla zkrocena lety výzkumu a vývoje, simulacemi a implementacemi na testnetech. Protokol důkazu podílem byl nezávisle implementován pěti samostatnými týmy (na exekuční i konsensuální vrstvě) v pěti programovacích jazycích, což poskytuje odolnost proti chybám klientů. + +Pro bezpečný vývoj a testování logiky konsensu důkazu podílem byl Beacon Chain spuštěn dva roky před implementací důkazu podílem na hlavní síti Etherea. Beacon Chain fungoval jako sandbox pro testování důkazu podílem, protože to byl živý blockchain implementující logiku konsensu důkazu podílem, ale bez dotyku reálných transakcí Etherea – v podstatě jen dosahoval konsensu sám o sobě. Jakmile byl po dostatečně dlouhou dobu stabilní a bez chyb, Beacon Chain byl „sloučen“ s hlavní sítí Etherea. To vše přispělo ke zkrocení složitosti důkazu podílem do té míry, že riziko nezamýšlených důsledků nebo chyb klienta bylo velmi nízké. + +### Vektor útoku {#attack-surface} + +Důkaz podílem je složitější než důkaz prací, což znamená, že existuje více potenciálních vektorů útoku, které je třeba řešit. Místo jedné peer-to-peer sítě spojující klienty existují dvě, z nichž každá implementuje samostatný protokol. To, že je v každém slotu předem vybrán jeden konkrétní validátor, který navrhuje blok, vytváří potenciál pro útok odepření služby, kdy velké množství síťového provozu vyřadí tohoto konkrétního validátora z provozu. + +Existují také způsoby, jak mohou útočníci pečlivě načasovat vydání svých bloků nebo atestací tak, aby je obdržela určitá část poctivé sítě, a ovlivnit je tak, aby hlasovali určitým způsobem. Nakonec může útočník jednoduše nashromáždit dostatek ETH k uzamčení a ovládnout mechanismus konsensu. Každý z těchto [vektorů útoku má přidruženou obranu](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ale v rámci důkazu prací tyto vektory neexistují. + +## Decentralizace {#decentralization} + +Důkaz podílem je decentralizovanější než důkaz prací, protože závody ve zbrojení těžebního hardwaru mají tendenci vytlačovat jednotlivce a malé organizace z trhu. I když kdokoli může technicky začít těžit se skromným hardwarem, jeho pravděpodobnost získání jakékoli odměny je mizivě malá ve srovnání s institucionálními těžebními operacemi. U důkazu podílem jsou náklady na uzamčení a procentuální návratnost tohoto vkladu pro všechny stejné. Provoz validátoru v současné době stojí 32 ETH. + +Na druhou stranu, vynález derivátů tekutého stakingu vedl k obavám z centralizace, protože několik velkých poskytovatelů spravuje velké množství uzamčených ETH. To je problematické a je třeba to co nejdříve napravit, ale je to také složitější, než se zdá. Centralizovaní poskytovatelé stakingu nemusí nutně mít centralizovanou kontrolu nad validátory – často je to jen způsob, jak vytvořit centrální pool ETH, který může mnoho nezávislých operátorů uzlů stakovat, aniž by každý účastník potřeboval vlastních 32 ETH. + +Nejlepší možností pro Ethereum je, aby byly validátory provozovány lokálně na domácích počítačích, což maximalizuje decentralizaci. Proto se Ethereum brání změnám, které zvyšují hardwarové nároky na provoz uzlu/validátoru. + +## Udržitelnost {#sustainability} + +Důkaz podílem je uhlíkově nenáročný způsob zabezpečení blockchainu. V rámci důkazu prací těžaři soutěží o právo vytěžit blok. Těžaři jsou úspěšnější, když mohou provádět výpočty rychleji, což motivuje k investicím do hardwaru a spotřeby energie. To bylo pozorováno u Etherea předtím, než přešlo na důkaz podílem. Krátce před přechodem na důkaz podílem Ethereum spotřebovávalo přibližně 78 TWh/rok – tolik jako malá země. Přechod na důkaz podílem však snížil tyto energetické výdaje o ~99,98 %. Díky důkazu podílem se z Etherea stala energeticky účinná a nízkouhlíková platforma. + +[Více o spotřebě energie Etherea](/energy-consumption) + +## Vydávání {#issuance} + +Ethereum s důkazem podílem může platit za svou bezpečnost vydáváním mnohem menšího počtu mincí než Ethereum s důkazem prací, protože validátoři nemusí platit vysoké náklady na elektřinu. V důsledku toho může ETH snížit svou inflaci nebo se dokonce stát deflačním, když se spálí velké množství ETH. Nižší míra inflace znamená, že zabezpečení Etherea je levnější, než bylo u důkazu prací. + +## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} + +Podívejte se, jak Justin Drake vysvětluje výhody důkazu podílem oproti důkazu prací: + + + +## Další čtení {#further-reading} + +- [Vitalikova filozofie návrhu důkazu podílem](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Vitalikovy časté dotazy k důkazu podílem](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [Video „Jednoduše vysvětleno“ o PoS vs. PoW](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..ff583b9c406 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "Odměny a tresty v mechanismu proof-of-stake" +description: "Seznamte se s pobídkami v rámci protokolu v Ethereu s mechanismem proof-of-stake." +lang: cs +--- + +Ethereum je zabezpečeno pomocí své nativní kryptoměny, etheru (ETH). Provozovatelé uzlů, kteří se chtějí podílet na validaci bloků a určování hlavy řetězce, vkládají ether do [vkladového kontraktu](/staking/deposit-contract/) na Ethereu. Poté jsou placeni v etheru za provozování softwaru validátoru, který kontroluje platnost nových bloků přijatých přes síť peer-to-peer a aplikuje algoritmus pro výběr větve k identifikaci hlavy řetězce. + +Validátor má dvě hlavní role: 1) kontroluje nové bloky a „atestuje“ je, pokud jsou platné, 2) navrhuje nové bloky, když je náhodně vybrán z celkového poolu validátorů. Pokud validátor některý z těchto úkolů na vyžádání nesplní, přijde o výplatu v etheru. Validátoři jsou také někdy pověřeni agregací podpisů a účastí v synchronizačních výborech. + +Existují také některé akce, které je velmi obtížné provést náhodou a které značí nějaký zlovolný úmysl, jako je navrhování více bloků pro stejný slot nebo atestování více bloků pro stejný slot. Jedná se o chování, které je postihnutelné „slashingem“ a jehož výsledkem je, že validátorovi je spálena určitá částka etheru (až 1 ETH), než je validátor odstraněn ze sítě, což trvá 36 dní. Ether validátora postiženého slashingem se během období odchodu pomalu vytrácí, ale 18. den obdrží „korelační penalizaci“, která je větší, když je ve stejnou dobu postiženo slashingem více validátorů. Struktura pobídek mechanismu konsenzu tedy odměňuje poctivost a trestá špatné aktéry. + +Všechny odměny a tresty se uplatňují jednou za epochu. + +Pro více podrobností čtěte dál... + +## Odměny a tresty {#rewards} + +### Odměny {#rewards} + +Validátoři dostávají odměny, když hlasují v souladu s většinou ostatních validátorů, když navrhují bloky a když se účastní synchronizačních výborů. Hodnota odměn v každé epoše se vypočítává ze `základní odměny` (`base_reward`). Jedná se o základní jednotku, ze které se počítají ostatní odměny. `base_reward` představuje průměrnou odměnu, kterou validátor obdrží za optimálních podmínek za epochu. Vypočítává se z efektivního zůstatku validátora a celkového počtu aktivních validátorů následovně: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +kde `base_reward_factor` je 64, `base_rewards_per_epoch` je 4 a `sum(active balance)` je celkový uzamčený ether napříč všemi aktivními validátory. + +To znamená, že základní odměna je úměrná efektivnímu zůstatku validátora a nepřímo úměrná počtu validátorů v síti. Čím více validátorů, tím větší je celkové vydávání (jako `sqrt(N)`), ale tím menší je `base_reward` na validátora (jako `1/sqrt(N)`). Tyto faktory ovlivňují RPSN pro staking uzel. Odůvodnění si přečtěte v [poznámkách Vitalika](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +Celková odměna se pak vypočítá jako součet pěti složek, z nichž každá má váhu, která určuje, kolik každá složka přispěje k celkové odměně. Složky jsou: + +``` +1. hlasování o zdroji: validátor včas hlasoval pro správný zdrojový kontrolní bod +2. hlasování o cíli: validátor včas hlasoval pro správný cílový kontrolní bod +3. hlasování o hlavě: validátor včas hlasoval pro správný hlavní blok +4. odměna synchronizačního výboru: validátor se zúčastnil synchronizačního výboru +5. odměna navrhovatele: validátor navrhl blok ve správném slotu +``` + +Váhy pro každou složku jsou následující: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +Součet těchto vah je 64. Odměna se vypočítá jako součet příslušných vah dělený 64. Validátor, který včas hlasoval o zdroji, cíli a hlavě, navrhl blok a zúčastnil se synchronizačního výboru, může obdržet `64/64 * base_reward == base_reward`. Validátor však obvykle není navrhovatelem bloku, takže jeho maximální odměna je `64-8 / 64 * base_reward == 7/8 * base_reward`. Validátoři, kteří nejsou ani navrhovateli bloků, ani v synchronizačním výboru, mohou obdržet `64-8-2 / 64 * base_reward == 6.75/8 * base_reward`. + +Další odměna se přidává jako pobídka pro rychlé atestace. Jedná se o `inclusion_delay_reward`. Její hodnota se rovná `base_reward` vynásobené `1/zpoždění`, kde `zpoždění` je počet slotů oddělujících návrh bloku a atestaci. Pokud je například atestace odeslána do jednoho slotu od návrhu bloku, atestující obdrží `base_reward * 1/1 == base_reward`. Pokud atestace dorazí v dalším slotu, atestující obdrží `base_reward * 1/2` a tak dále. + +Navrhovatelé bloků dostávají `8 / 64 * base_reward` za **každou platnou atestaci** zahrnutou v bloku, takže skutečná hodnota odměny se škáluje s počtem atestujících validátorů. Navrhovatelé bloků mohou také zvýšit svou odměnu tím, že do svého navrhovaného bloku zahrnou důkazy o nesprávném chování jiných validátorů. Tyto odměny jsou „pobídkami“, které podporují poctivost validátorů. Navrhovatel bloku, který zahrne slashing, bude odměněn částkou `slashed_validators_effective_balance / 512`. + +### Tresty {#penalties} + +Dosud jsme se zabývali dokonale se chovajícími validátory, ale co validátoři, kteří nehlasují včas o hlavě, zdroji a cíli nebo tak činí pomalu? + +Tresty za zmeškání hlasování o cíli a zdroji se rovnají odměnám, které by atestující obdržel, kdyby je odeslal. To znamená, že místo přičtení odměny k jejich zůstatku jim bude z jejich zůstatku odečtena stejná hodnota. Za zmeškání hlasování o hlavě se neuděluje žádný trest (tj. hlasy o hlavě se pouze odměňují, nikdy se netrestají). S `inclusion_delay` není spojen žádný trest – odměna se prostě nepřičte k zůstatku validátora. Není ani žádný trest za nenavrhnutí bloku. + +Přečtěte si více o odměnách a trestech ve [specifikacích konsenzu](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Odměny a tresty byly upraveny ve vylepšení Bellatrix – podívejte se, jak o tom diskutují Danny Ryan a Vitalik v tomto [videu Peep an EIP](https://www.youtube.com/watch?v=iaAEGs1DMgQ). + +## Slashing {#slashing} + +Slashing je závažnější akce, která má za následek nucené odstranění validátora ze sítě a s tím spojenou ztrátu jeho uzamčeného etheru. Existují tři způsoby, jak může být validátor postižen slashingem, přičemž všechny se rovnají nečestnému navrhování nebo atestaci bloků: + +- Navrhováním a podepisováním dvou různých bloků pro stejný slot +- Atestací bloku, který \"obklopuje\" jiný (což v podstatě mění historii) +- \"Dvojitým hlasováním\" prostřednictvím atestace dvou kandidátů na stejný blok + +Pokud jsou tyto akce zjištěny, je validátor postižen slashingem. To znamená, že pro validátora s 32 ETH je okamžitě spáleno 0,0078125 (lineárně škálováno s aktivním zůstatkem) a poté začíná 36denní období odstraňování. Během tohoto období odstraňování se vklad validátora postupně snižuje. V polovině (18. den) se uplatní dodatečný trest, jehož velikost se škáluje s celkovým uzamčeným etherem všech validátorů postižených slashingem v 36 dnech před událostí slashingu. To znamená, že když je více validátorů postiženo slashingem, velikost trestu se zvyšuje. Maximální trest slashingem je plný efektivní zůstatek všech postižených validátorů (tj. pokud je slashingem postiženo mnoho validátorů, mohou přijít o celý svůj vklad). Na druhou stranu, jedna izolovaná událost slashingu spálí pouze malou část vkladu validátora. Tento trest v polovině období, který se škáluje s počtem validátorů postižených slashingem, se nazývá \"korelační penalizace\". + +## Únik z nečinnosti {#inactivity-leak} + +Pokud konsensuální vrstva neprovede finalizaci déle než čtyři epochy, aktivuje se nouzový protokol nazvaný \"únik z nečinnosti\". Konečným cílem úniku z nečinnosti je vytvořit podmínky nutné k tomu, aby řetězec obnovil finalitu. Jak bylo vysvětleno výše, finalita vyžaduje, aby se dvoutřetinová většina celkového uzamčeného etheru shodla na zdrojových a cílových kontrolních bodech. Pokud se validátoři představující více než 1/3 všech validátorů odpojí nebo neodešlou správné atestace, není možné, aby dvoutřetinová supervětšina finalizovala kontrolní body. Únik z nečinnosti umožňuje, aby se vklad patřící neaktivním validátorům postupně snižoval, dokud nebudou ovládat méně než 1/3 celkového vkladu, což umožní zbývajícím aktivním validátorům finalizovat řetězec. Ať je pool neaktivních validátorů jakkoli velký, zbývající aktivní validátoři nakonec ovládnou >2/3 vkladu. Ztráta vkladu je silnou pobídkou pro neaktivní validátory, aby se co nejdříve znovu aktivovali! Scénář úniku z nečinnosti nastal na testovací síti Medalla, když se < 66 % aktivních validátorů nebylo schopno shodnout na aktuální hlavě blockchainu. Byl aktivován únik z nečinnosti a finalita byla nakonec obnovena! + +Návrh odměn, trestů a slashingu v rámci mechanismu konsenzu podporuje jednotlivé validátory, aby se chovali správně. Z těchto návrhových rozhodnutí však vyplývá systém, který silně motivuje k rovnoměrnému rozložení validátorů mezi více klientů a měl by silně demotivovat dominanci jednoho klienta. + +## Další čtení {#further-reading} + +- [Vylepšení Etherea: Motivační vrstva](https://eth2book.info/altair/part2/incentives) +- [Pobídky v hybridním protokolu Casper od Etherea](https://arxiv.org/pdf/1903.04205.pdf) +- [Vitalikova anotovaná specifikace](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Tipy pro prevenci slashingu v Eth2](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [Analýza trestů za slashing podle EIP-7251](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_Zdroje_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..d4124d64f1c --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "Slabá subjektivita" +description: "Vysvětlení slabé subjektivity a její role v PoS Ethereu." +lang: cs +--- + +Subjektivita v blockchainech označuje spoléhání se na sociální informace za účelem dohody na aktuálním stavu. Může existovat více platných větví, ze kterých se vybírá podle informací získaných od ostatních peerů v síti. Opakem je objektivita, která se vztahuje na řetězce, kde existuje pouze jeden možný platný řetězec, na kterém se nutně shodnou všechny uzly použitím svých zakódovaných pravidel. Existuje také třetí stav, známý jako slabá subjektivita. Tento se vztahuje na řetězec, který může objektivně postupovat poté, co je sociálně získán určitý počáteční základ informací. + +## Předpoklady {#prerequisites} + +Abyste porozuměli této stránce, je nutné nejprve pochopit základy [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). + +## Jaké problémy řeší slabá subjektivita? {#problems-ws-solves} + +Subjektivita je přirozenou součástí blockchainů s důkazem podílem, protože výběr správného řetězce z několika větví se provádí sčítáním historických hlasů. Tím je blockchain vystaven několika vektorům útoku, včetně útoků na dálku (long-range attacks), při kterých uzly, které se účastnily velmi brzy v řetězci, udržují alternativní větev, kterou zveřejní mnohem později ve svůj vlastní prospěch. Alternativně, pokud 33 % validátorů vybere svůj vklad, ale bude pokračovat v potvrzování a vytváření bloků, mohou vygenerovat alternativní větev, která je v konfliktu s kanonickým řetězcem. Nové uzly nebo uzly, které byly dlouho offline, si nemusí být vědomy, že tito útočící validátoři vybrali své prostředky, takže by je útočníci mohli oklamat, aby sledovaly nesprávný řetězec. Ethereum může tyto vektory útoku vyřešit zavedením omezení, která omezují subjektivní aspekty mechanismu – a tedy i předpoklady důvěry – na naprosté minimum. + +## Kontrolní body slabé subjektivity {#ws-checkpoints} + +Slabá subjektivita je implementována v Ethereu s důkazem podílem pomocí „kontrolních bodů slabé subjektivity“. Jedná se o kořeny stavu, na kterých se všechny uzly v síti shodnou, že patří do kanonického řetězce. Slouží ke stejnému účelu „univerzální pravdy“ jako genesis bloky, až na to, že se nenacházejí na genesis pozici v blockchainu. Algoritmus pro výběr větve důvěřuje, že stav blockchainu definovaný v tomto kontrolním bodě je správný a že nezávisle a objektivně ověřuje řetězec od tohoto bodu dále. Kontrolní body fungují jako „limity pro vrácení zpět“, protože bloky umístěné před kontrolními body slabé subjektivity nelze změnit. Tím se narušují útoky na dálku jednoduše tím, že se větve vytvořené útoky na dálku definují jako neplatné v rámci návrhu mechanismu. Zajištění toho, aby kontrolní body slabé subjektivity byly odděleny menší vzdáleností než období pro výběr validátora, zajišťuje, že validátor, který větví řetězec, bude potrestán („slashed“) alespoň o nějakou prahovou částku, než bude moci vybrat svůj vklad, a že noví účastníci nemohou být podvedeni k tomu, aby se připojili k nesprávným větvím validátorů, jejichž vklad byl vybrán. + +## Rozdíl mezi kontrolními body slabé subjektivity a finalizovanými bloky {#difference-between-ws-and-finalized-blocks} + +Finalizované bloky a kontrolní body slabé subjektivity jsou uzly Etherea zpracovávány odlišně. Pokud se uzel dozví o dvou konkurenčních finalizovaných blocích, je mezi nimi rozpolcen – nemá žádný způsob, jak automaticky identifikovat, která je kanonická větev. To je příznakem selhání konsensu. Naproti tomu uzel jednoduše odmítne jakýkoli blok, který je v konfliktu s jeho kontrolním bodem slabé subjektivity. Z pohledu uzlu představuje kontrolní bod slabé subjektivity absolutní pravdu, kterou nelze podkopat novými znalostmi od ostatních peerů. + +## Jak slabá je slabá? {#how-weak-is-weak} + +Subjektivním aspektem důkazu podílem Etherea je požadavek na nedávný stav (kontrolní bod slabé subjektivity) z důvěryhodného zdroje, ze kterého se má synchronizovat. Riziko získání špatného kontrolního bodu slabé subjektivity je velmi nízké, protože je lze zkontrolovat oproti několika nezávislým veřejným zdrojům, jako jsou prohlížeče bloků nebo více uzlů. Nicméně pro spuštění jakékoli softwarové aplikace je vždy nutná určitá míra důvěry, například důvěra v to, že vývojáři softwaru vytvořili poctivý software. + +Kontrolní bod slabé subjektivity může být dokonce součástí klientského softwaru. Pravděpodobně může útočník poškodit kontrolní bod v softwaru a stejně tak snadno může poškodit i samotný software. Neexistuje žádná skutečná kryptoekonomická cesta, jak tento problém obejít, ale dopad nedůvěryhodných vývojářů je v Ethereu minimalizován tím, že existuje několik nezávislých klientských týmů, z nichž každý vytváří ekvivalentní software v různých jazycích, a všechny mají vlastní zájem na udržení poctivého řetězce. Prohlížeče bloků mohou také poskytovat kontrolní body slabé subjektivity nebo způsob, jak křížově ověřit kontrolní body získané odjinud oproti dalšímu zdroji. + +Nakonec lze kontrolní body vyžádat od jiných uzlů; například jiný uživatel Etherea, který provozuje plný uzel, může poskytnout kontrolní bod, který pak mohou validátoři ověřit oproti datům z prohlížeče bloků. Celkově lze říci, že důvěra v poskytovatele kontrolního bodu slabé subjektivity může být považována za stejně problematickou jako důvěra v klientské vývojáře. Celková požadovaná důvěra je nízká. Je důležité si uvědomit, že tyto úvahy se stávají důležitými pouze ve velmi nepravděpodobném případě, že se většina validátorů spikne a vytvoří alternativní větev blockchainu. Za jakýchkoli jiných okolností existuje pouze jeden řetězec Etherea, ze kterého lze vybírat. + +## Další čtení {#further-reading} + +- [Slabá subjektivita v Eth2](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: Jak jsem se naučil milovat slabou subjektivitu](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Slabá subjektivita (dokumentace Teku)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [Příručka ke slabé subjektivitě Fáze 0](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Analýza slabé subjektivity v Ethereu 2.0](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..eb8eb753cb2 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "Pověření k výběru" +description: "Vysvětlení typů pověření validátora k výběru (0x00, 0x01, 0x02) a jejich dopady na stakery Etherea." +lang: cs +--- + +Každý validátor má **pověření k výběru**, které určuje, jak a kam lze vybrat jeho stakované ETH a odměny. Typ pověření je určen prvním bajtem: `0x00`, `0x01` nebo `0x02`. Porozumění těmto typům je důležité pro validátory, kteří spravují svůj vklad. + +## 0x00: Pověření před upgradem Shapella {#0x00-credentials} + +Typ `0x00` je původní formát pověření k výběru z doby před upgradem Shapella (duben 2023). Validátoři s tímto typem pověření nemají nastavenou adresu pro výběr na exekuční vrstvě, což znamená, že jejich prostředky zůstávají uzamčeny na vrstvě konsenzu. Pokud stále máte pověření `0x00`, musíte provést upgrade na `0x01` nebo `0x02`, abyste mohli provádět jakékoli výběry. + +## 0x01: Zastaralá pověření k výběru {#0x01-credentials} + +Typ `0x01` byl zaveden s upgradem Shapella a stal se standardem pro validátory, kteří si chtěli nastavit adresu pro výběr na exekuční vrstvě. S pověřením `0x01`: + +- Jakýkoli zůstatek nad 32 ETH je **automaticky převeden** na vaši adresu pro výběr +- Úplné exity procházejí standardní frontou pro exity +- Odměny nad 32 ETH se nemohou úročit – jsou pravidelně převáděny pryč + +**Proč někteří validátoři stále používají 0x01:** Je to jednodušší a znají to. Mnoho validátorů provedlo vklad po upgradu Shapella a tento typ již mají a funguje dobře pro ty, kteří chtějí automatické výběry přebytečného zůstatku. + +**Proč se nedoporučuje:** S typem `0x01` ztrácíte možnost úročit odměny nad 32 ETH. Každý přebytek je automaticky převeden pryč, což omezuje výdělkový potenciál vašeho validátora a vyžaduje samostatnou správu vybraných prostředků. + +## 0x02: Pověření k výběru s úročením {#0x02-credentials} + +Typ `0x02` byl zaveden s upgradem Pectra a dnes je pro validátory **doporučenou volbou**. Validátoři s pověřením `0x02` se někdy nazývají "úročící validátoři". + +S pověřením `0x02`: + +- Odměny nad 32 ETH se **úročí** v přírůstcích po 1 ETH až do maximálního efektivního zůstatku 2048 ETH +- O částečné výběry je nutné požádat ručně (automatické převody se provádějí pouze nad hranicí 2048 ETH) +- Validátoři mohou sloučit více validátorů s vkladem 32 ETH do jednoho validátora s vyšším zůstatkem +- Úplné exity jsou stále podporovány prostřednictvím standardní fronty pro exity + +Jak částečné výběry, tak slučování lze provést prostřednictvím [akcí pro validátory na Launchpadu](https://launchpad.ethereum.org/en/validator-actions). + +**Proč by měli validátoři preferovat 0x02:** Nabízí lepší kapitálovou efektivitu díky úročení, větší kontrolu nad tím, kdy dochází k výběrům, a podporuje slučování validátorů. Pro sólo stakery, kteří v průběhu času shromažďují odměny, to znamená, že jejich efektivní zůstatek – a tedy i jejich odměny – mohou růst nad 32 ETH bez ručního zásahu. + +**Důležité:** Jakmile provedete převod z `0x01` na `0x02`, nemůžete se vrátit zpět. + +Podrobného průvodce převodem na pověření typu 2 a funkcí MaxEB najdete na [stránce s vysvětlením MaxEB](/roadmap/pectra/maxeb/). + +## Co si mám vybrat? {#what-should-i-pick} + +- **Noví validátoři:** Zvolte `0x02`. Je to moderní standard s lepším úročením a flexibilitou. +- **Stávající validátoři s pověřením 0x01:** Zvažte převod na `0x02`, pokud chcete, aby se odměny úročily nad 32 ETH, nebo plánujete sloučit validátory. +- **Stávající validátoři s pověřením 0x00:** Okamžitě proveďte upgrade – bez aktualizace pověření nemůžete provádět výběry. Nejprve musíte provést převod na `0x01`, poté můžete provést převod na `0x02`. + +## Nástroje pro správu pověření k výběru {#withdrawal-credential-tools} + +Několik nástrojů podporuje výběr nebo převod mezi typy pověření: + +- **[Ethereum Staking Launchpad](https://launchpad.ethereum.org/en/validator-actions)** – oficiální nástroj pro vklady a správu validátorů, včetně převodů pověření a slučování +- **[Pectra Staking Manager](https://pectrastaking.com)** – webové rozhraní s podporou wallet-connect pro převody a slučování +- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** – nástroj příkazového řádku pro hromadné převody +- **[Ethereal](https://github.com/wealdtech/ethereal)** – nástroj CLI pro operace v síti Ethereum včetně správy validátorů + +Úplný seznam nástrojů pro slučování a podrobné pokyny k převodu najdete v části [Nástroje pro slučování MaxEB](/roadmap/pectra/maxeb/#consolidation-tooling). + +## Další čtení {#further-reading} + +- [Klíče v síti Ethereum s proof-of-stake](/developers/docs/consensus-mechanisms/pos/keys/) – zjistěte více o klíčích validátorů a o tom, jak souvisí s pověřeními k výběru +- [MaxEB](/roadmap/pectra/maxeb/) – podrobný průvodce upgradem Pectra a funkcí maximálního efektivního zůstatku diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..99b6142b9ff --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: Proof-of-work (PoW) +description: "Vysvětlení konsensuálního protokolu proof of work a jeho role v Ethereum síti." +lang: cs +--- + +Síť Ethereum začala používat mechanismus konsenzu, který zahrnoval **[důkaz prací (PoW)](/developers/docs/consensus-mechanisms/pow)**. Tento mechanismus umožňoval uzlům sítě Ethereum shodnout se na stavu všech informací zaznamenaných na blockchainu Etherea a bránil určitým druhům ekonomických útoků. V roce 2022 však Ethereum přešlo z důkazu prací na [důkaz podílem](/developers/docs/consensus-mechanisms/pos). + + + + + + Proof-of-work je nyní zastaralý. Ethereum už proof-of-work nepoužívá jako součást svého konsensuálního mechanismu. Místo toho používá proof-of-stake. Přečtěte si více o [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) a [uzamčení](/staking/). + + + + +## Předpoklady {#prerequisites} + +Abyste lépe porozuměli této stránce, doporučujeme vám si nejprve přečíst o [transakcích](/developers/docs/transactions/), [blocích](/developers/docs/blocks/) a [mechanismech konsenzu](/developers/docs/consensus-mechanisms/). + +## Co je důkaz prací (PoW)? {#what-is-pow} + +Nakamotův konsensus, který využívá důkaz prací, je mechanismus, který kdysi umožňoval decentralizované síti Ethereum dosáhnout konsenzu (tj. shody všech uzlů) na věcech, jako jsou zůstatky na účtech a pořadí transakcí. Tento mechanismus zabránil uživatelům v „dvojím utracení“ prostředků a zajistil, že Ethereum blockchain bylo mimořádně obtížné napadnout nebo s ním manipulovat. Tyto bezpečnostní vlastnosti nyní pocházejí z důkazu podílem za použití mechanismu konsenzu známého jako [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). + +## Důkaz prací a těžba {#pow-and-mining} + +Proof-of-work je základní algoritmus, který stanovuje obtížnost a pravidla pro práci těžařů na proof-of-work blockchainech. Těžba je samotná "práce". Těžbou je myšleno přidávání platných bloků do řetězce. To je důležité, protože délka řetězce pomáhá síti sledovat správnou větev blockchainu. Čím více "práce" je vykonáno, tím delší je řetězec a čím vyšší je číslo bloku, tím jistější si síť může být aktuálním stavem věcí. + +[Více o těžbě](/developers/docs/consensus-mechanisms/pow/mining/) + +## Jak funguje proof-of-work na Ethereu? Jak to funguje {#how-it-works} + +Transakce na Ethereu se zpracovávají do bloků. Na nyní zastaralém proof-of-work Ethereu každý blok obsahoval: + +- obtížnost bloku - například: 3,324,092,183,262,715 +- mixHash – například: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce – například: `0xd3ee432b4fb3d26b` + +Tato data bloku byla přímo spojena s proof-of-work. + +### Práce v důkazu prací {#the-work} + +Protokol proof-of-work, Ethash, vyžadoval, aby těžaři prošli intenzivním závodem sestávajícím z pokusů a omylů, aby našli jednorázové číslo bloku. Pouze bloky s platným jednorázovým číslem mohly být přidány do řetězce. + +Při závodě o vytvoření bloku těžař opakovaně procházel datovou sadu, kterou bylo možné získat pouze stažením a provozováním celého řetězce (což těžaři dělají), pomocí matematické funkce. Tato datová sada byla použita k vygenerování mixHashe, který byl pod cílovou hodnotou určenou obtížností bloku. Nejlepší způsob, jak toho dosáhnout, je metoda pokusů a omylů. + +Obtížnost určovala cíl pro hash. Čím nižší je cílová hodnota, tím menší je množina platných hashů. Jakmile byl hash vygenerován, bylo pro ostatní těžaře a klienty velmi snadné jej ověřit. I malá změna v transakci by vedla k úplně jinému hashi, což by signalizovalo podvod. + +Díky hashování je podvod snadno odhalitelný. Ale proof-of-work jako proces byl také velkým odrazujícím prvkem proti útokům na řetězec. + +### Důkaz prací a bezpečnost {#security} + +Těžaři byli motivováni vykonávat tuto práci na Ethereum Mainnetu. Podskupina těžařů měla jen malou motivaci k tomu, aby si založila vlastní řetězec - podkopává to celý systém. Blockchainy se spoléhají na to, že mají jediný stav jako zdroj pravdy. + +Cílem proof-of-work bylo prodloužit řetězec. Nejdelší řetězec byl považován za nejvěrohodnější, protože na něm bylo provedeno nejvíce výpočetní práce. V rámci Ethereum systému PoW bylo téměř nemožné vytvářet nové bloky, které by vymazaly transakce, vytvořily falešné bloky nebo udržovaly druhý řetězec. To proto, že by těžař s úmyslem poškodit blockchain musel vždy vypočítat jedinečné číslo bloku rychleji než ostatní. + +Aby zlý těžař mohl konzistentně vytvářet škodlivé, ale platné bloky, musel by mít více než 51 % výpočetní síly sítě, aby porazil ostatní těžaře. Takové množství „práce“ vyžaduje značné množství drahé výpočetní síly a náklady na energii by mohly dokonce převýšit zisky útoku. + +### Ekonomika důkazu prací {#economics} + +Proof-of-work byl také zodpovědný za vytváření nové měny v systému a za motivaci těžařů k vykonávání práce. + +Od [upgradu Constantinople](/ethereum-forks/#constantinople) byli těžaři, kteří úspěšně vytvořili blok, odměněni dvěma nově vyraženými ETH a částí transakčních poplatků. Ommer bloky byly také kompenzovány částkou 1,75 ETH. Ommer bloky byly platné bloky vytvořené těžařem prakticky ve stejnou dobu jako jiný těžař vytvořil kanonický blok, přičemž rozhodující bylo, který blok byl přidán ke stávajícímu řetězci jako první. Ommer bloky se obvykle objevovaly kvůli latenci sítě. + +## Konečnost {#finality} + +Transakce má na Ethereu „konečnost“, když je součástí bloku, který se nemůže změnit. + +Protože těžaři pracovali decentralizovaným způsobem, mohly být současně vytěženy dva platné bloky. To vedlo k dočasnémuu větvení řetězce. Nakonec se jeden z těchto řetězců stal přijatým řetězcem poté, co byly vytěženy a přidány další bloky, čímž se stal delším. + +Aby se věci ještě více zkomplikovaly, transakce, které byly zamítnuty na dočasné větvi, nemusely být zahrnuty v přijatém řetězci. To znamená, že mohlo dojít k jejich zrušení. Konečnost se tedy týká doby, po kterou byste měli vyčkat, než lze transakci považovat za nevratnou. V předchozím Ethereu s důkazem prací platilo, že čím více bloků bylo vytěženo nad konkrétním blokem `N`, tím vyšší byla důvěra, že transakce v `N` byly úspěšné a nebudou zrušeny. Nyní, s proof-of-stake, je konečnost explicitní vlastností bloku, nikoli probabilistickou. + +## Spotřeba energie u důkazu prací {#energy} + +Hlavní kritikou proof-of-work je množství energie potřebné k udržení bezpečnosti sítě. Aby si Ethereum udrželo míru bezpečnosti a decentralizace, spotřebovávalo velké množství energie. Krátce před přechodem na důkaz podílem těžaři Etherea kolektivně spotřebovávali přibližně 70 TWh/rok (přibližně stejně jako Česká republika – podle [digiconomist](https://digiconomist.net/) k 18. červenci 2022). + +## Výhody a nevýhody {#pros-and-cons} + +| Plusy | Minusy | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Proof-of-work je neutrální. Pro začátek nepotřebujete ETH a odměny za bloky vám umožní přejít z 0ETH do kladného zůstatku. U [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) potřebujete pro začátek ETH. | Proof-of-work spotřebovává tolik energie, že je škodlivý pro životní prostředí. | +| Proof-of-work je osvědčený a vyzkoušený konsensuální mechanismus, který udržoval Bitcoin a Ethereum bezpečné a decentralizované po mnoho let. | Pokud chcete těžit, potřebujete tak specializované vybavení, že je to pro začátek velká investice. | +| Ve srovnání s proof-of-stake je jeho implementace relativně snadná. | Vzhledem k rostoucí potřebě výpočtů by těžební pooly mohly potenciálně ovládnout těžbu, což by vedlo k centralizaci a bezpečnostním rizikům. | + +## Srovnání s důkazem podílem {#compared-to-pos} + +Z obecného pohledu má proof-of-stake stejný cíl jako proof-of-work: Pomoci decentralizované síti bezpečně dosáhnout konsensu. Má však některé rozdíly v procesu a personálu: + +- Proof-of-stake nahrazuje důležitost výpočetní síly stakovaným ETH. +- Proof-of-stake nahrazuje těžaře validátory. Validátoři uzamikají své ETH, aby aktivovali schopnost vytvářet nové bloky. +- Validátoři nesoutěží o vytváření bloků, místo toho jsou náhodně vybíráni algoritmem. +- Konečnost je jasnější: pokud se v určitých kontrolních bodech 2/3 validátorů shodnou na stavu bloku, je považován za konečný. Validátoři na to musí vsadit celý svůj vklad, takže pokud se pokusí o tajnou dohodu bokem, přijdou o celý svůj vklad. + +[Více o důkazu podílem](/developers/docs/consensus-mechanisms/pos/) + +## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} + + + +## Další čtení {#further-reading} + +- [Většinový útok](https://en.bitcoin.it/wiki/Majority_attack) +- [O finalitě vypořádání](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### Videa {#videos} + +- [Technické vysvětlení protokolů důkazu prací](https://youtu.be/9V1bipPkCTU) + +## Související témata {#related-topics} + +- [Těžba](/developers/docs/consensus-mechanisms/pow/mining/) +- [Důkaz podílem](/developers/docs/consensus-mechanisms/pos/) +- [Důkaz autoritou](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..ff073791510 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "Těžba" +description: "Vysvětlení, jak fungovala těžba na Ethereu." +lang: cs +--- + + + + + +Proof-of-work již není základním mechanismem konsensu Etherea, což znamená, že těžení bylo vypnuto. Místo toho je Ethereum zabezpečeno validátory, kteří stakují ETH. Své ETH můžete začít stakeovat hned dnes. Přečtěte si více o Sloučení, proof-of-stake a stakování. Tato stránka má pouze historický význam. + + + + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky doporučujeme si nejprve přečíst o [transakcích](/developers/docs/transactions/), [blocích](/developers/docs/blocks/) a [důkazu prací](/developers/docs/consensus-mechanisms/pow/). + +## Co je to těžba Etherea? {#what-is-ethereum-mining} + +Těžení je proces vytváření bloků transakcí, které byly přidávány do blockchainu Etherea v dříve používané architektuře proof-of-work. + +Slovo „těžení“ pochází z analogie se zlatem v kontextu kryptoměn. Zlaté nebo cenné kovy jsou vzácné, stejně jako digitální tokeny, a jediným způsobem, jak zvýšit jejich celkový objem v systému proof-of-work, je těžení. Na proof-of-work Ethereu byl jediný způsob, jak vydávat nové ETH, právě těžba. Na rozdíl od zlata nebo cenných kovů však těžení Etherea také sloužilo k zabezpečení sítě tím, že vytvářelo, ověřovalo, publikovalo a šířilo bloky blockchainu. + +Těžení etheru = Zabezpečení sítě + +Těžení je krví každého blockchainu založeného na proof-of-work. Těžaři Etherea – počítače, na kterých je spuštěn software – používali před přechodem na proof-of-stake svůj čas a výpočetní výkon ke zpracovávání transakcí a vytváření bloků. + +## Proč těžaři existují? {#why-do-miners-exist} + +V decentralizovaných systémech, jako je Ethereum, musíme zajistit, aby se všichni shodli na pořadí transakcí. Těžaři tomu napomáhají tím, že řeší výpočetně náročné "hádanky" a vytvářejí tak bloky, které slouží k zabezpečení sítě před útoky. + +[Více o důkazu prací](/developers/docs/consensus-mechanisms/pow/) + +Dříve měl každý možnost těžit na síti Ethereum pomocí svého počítače. Avšak ne každý mohl těžit ether (ETH) ziskově. V mnoha případech museli těžaři investovat do specializovaného počítačového hardwaru a mít přístup k levným zdrojům energie. Průměrný počítač pravděpodobně nikdy nevydělal dost prostředků na pokrytí nákladů spojených s těžením. + +### Náklady na těžbu {#cost-of-mining} + +- Potenciální náklady na hardware potřebný k vybudování a údržbě těžebního zařízení +- Náklady napájení těžebního zařízení elektřinou +- Pokud jste těžili v těžebním poolu, účtovaly vám tyto pooly obvykle pevný procentuální poplatek z každého bloku generovaného poolem +- Potenciální náklady na vybavení pro podporu těžebního zařízení (ventilace, monitoring energie, elektrické vedení atd.) + +Pro podrobnější prozkoumání ziskovosti těžby použijte kalkulačku těžby, například tu, kterou poskytuje [Etherscan](https://etherscan.io/ether-mining-calculator). + +## Jak se těžily transakce na Ethereu {#how-ethereum-transactions-were-mined} + +Následující text je přehledem způsobu těžby na proof-of-work Ethereu. Analogický popis tohoto procesu pro Ethereum s důkazem podílem najdete [zde](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos). + +1. Uživatel napíše a podepíše požadavek na [transakci](/developers/docs/transactions/) privátním klíčem nějakého [účtu](/developers/docs/accounts/). +2. Uživatel odešle požadavek na transakci do celé sítě Ethereum z nějakého [uzlu](/developers/docs/nodes-and-clients/). +3. Jakmile se o novém požadavku na transakci dozví, každý uzel v Ethereum síti přidá požadavek do svého lokálního mempoolu, seznamu všech požadavků na transakci, o kterých se dozvěděl a které ještě nebyly odevzdány v bloku do blockchainu. +4. V určitém okamžiku těžební uzel agreguje několik desítek nebo stovek požadavků na transakce do potenciálního [bloku](/developers/docs/blocks/) tak, aby maximalizoval [transakční poplatky](/developers/docs/gas/), které vydělá, a zároveň se udržel pod palivovým limitem bloku. Těžební uzel pak: + 1. Ověří platnost každého požadavku na transakci (tj. nikdo se nepokouší převést ether z účtu, pro který nevytvořil podpis, požadavek není chybný atd.), a poté provede kód požadavku, čímž změní stav své lokální kopie EVM. Těžař obdrží transakční poplatek za každý takový požadavek na svůj vlastní účet. + 2. Zahájí proces vytváření „certifikátu legitimity“ důkazu prací pro potenciální blok, jakmile jsou všechny požadavky na transakce v bloku ověřeny a provedeny na místní kopii EVM. +5. Nakonec těžař dokončí vytvoření certifikátu pro blok, který obsahuje náš konkrétní požadavek na transakci. Těžař pak vyšle dokončený blok, který obsahuje certifikát a kontrolní součet nárokovaného nového stavu EVM. +6. Ostatní uzly se o novém bloku dozvědí. Ověří certifikát, samy provedou všechny transakce na bloku (včetně transakce původně vyslané naším uživatelem) a ověří, zda se kontrolní součet jejich nového stavu EVM po provedení všech transakcí shoduje s kontrolním součtem stavu deklarovaného blokem těžaře. Teprve poté tyto uzly připojí tento blok na konec svého blockchainu a přijmou nový stav EVM jako kanonický stav. +7. Každý uzel odstraní všechny transakce v novém bloku ze svého lokálního mempoolu nesplněných transakčních požadavků. +8. Nové uzly, které se připojují k síti, stahují postupně všechny bloky, včetně bloku obsahujícího naši sledovanou transakci. Inicializují lokální kopii EVM (která začíná prázdném stavu) a poté procházejí procesem provádění všech transakcí v každém bloku nad svou lokální kopií EVM a cestou ověřují kontrolní součty stavu v každém bloku. + +Každá transakce je vytěžena (zařazena do nového bloku a poprvé propagována) jednou, ale provedena a ověřena každým účastníkem procesu postupu kanonického stavu EVM. To zdůrazňuje jednu z ústředních manter blockchainu: **Nevěř, ověřuj**. + +## Ommer (uncle) bloky {#ommer-blocks} + +Těžení bloků v proof-of-work bylo pravděpodobnostní, což znamená, že někdy byly současně publikovány dva platné bloky kvůli latenci sítě. V takovém případě musel protokol určit nejdelší (a tedy nejvíce „platný“) řetězec, přičemž zajistil spravedlnost vůči těžařům tím, že částečně odměnil nezařazený platný blok. To podpořilo další decentralizaci sítě, protože menší těžaři, kteří mohli čelit větší latenci, mohli stále generovat výnosy prostřednictvím odměn za [ommer](/glossary/#ommer) bloky. + +Termín „ommer“ je preferovaný genderově neutrální termín pro sourozence rodičovského bloku, ale někdy se také používá termín „strýc“ (uncle). **Od přechodu Etherea na důkaz podílem se ommer bloky již netěží**, protože v každém slotu je zvolen pouze jeden navrhovatel. Tuto změnu můžete vidět na [historickém grafu](https://ycharts.com/indicators/ethereum_uncle_rate) ommer bloků, které byly těženy. + +## Vizuální ukázka {#a-visual-demo} + +Podívejte se, jak vás Austin provede těžbou a PoS blockchainem. + + + +## Algoritmus těžby {#mining-algorithm} + +Hlavní síť Ethereum kdy používala pouze jeden algoritmus těžby – ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash byl nástupcem původního R&D algoritmu známého jako ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/). + +[Více o algoritmech těžby](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## Související témata {#related-topics} + +- [Palivo](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [Důkaz prací](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..262a81c7f07 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,329 @@ +--- +title: Dagger-Hashimoto +description: "Podrobný pohled na algoritmus Dagger-Hashimoto." +lang: cs +--- + +Dagger-Hashimoto byla původní výzkumná implementace a specifikace těžebního algoritmu Etherea. Dagger-Hashimoto byl nahrazen [Ethash](#ethash). Těžba byla zcela vypnuta při [Sloučení](/roadmap/merge/) dne 15. září 2022. Od té doby je Ethereum zabezpečeno pomocí mechanismu [důkazu podílem](/developers/docs/consensus-mechanisms/pos). Tato stránka má historický význam – informace na ní již nejsou pro Ethereum po Sloučení relevantní. + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky doporučujeme si nejprve přečíst o [konsensu důkazu prací](/developers/docs/consensus-mechanisms/pow), [těžbě](/developers/docs/consensus-mechanisms/pow/mining) a [těžebních algoritmech](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms). + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto se snaží splnit dva cíle: + +1. **Odolnost vůči ASIC**: výhoda plynoucí z vytvoření specializovaného hardwaru pro tento algoritmus by měla být co nejmenší +2. **Ověřitelnost lehkým klientem**: blok by měl být efektivně ověřitelný lehkým klientem. + +S další úpravou také specifikujeme, jak v případě potřeby splnit třetí cíl, avšak za cenu zvýšené složitosti: + +**Úplné úložiště řetězce**: těžba by měla vyžadovat uložení celého stavu blockchainu (kvůli nepravidelné struktuře stavového stromu Ethereum očekáváme, že bude možné určité prořezávání, zejména některých často používaných kontraktů, ale chceme to minimalizovat). + +## Generování DAG {#dag-generation} + +Kód algoritmu bude definován níže v jazyce Python. Nejprve uvedeme `encode_int` pro převádění celých čísel bez znaménka o zadané přesnosti na řetězce. Je uvedena i jeho inverzní funkce: + +```python +NUM_BITS = 512 + +def encode_int(x): + "Zakóduje celé číslo x jako řetězec 64 znaků pomocí schématu big-endian" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "Dekóduje celé číslo x z řetězce pomocí schématu big-endian" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +Dále předpokládáme, že `sha3` je funkce, která přijímá celé číslo a vrací celé číslo, a `dbl_sha3` je funkce double-sha3; pokud převádíte tento referenční kód do implementace, použijte: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### Parametry {#parameters} + +Parametry použité pro algoritmus jsou: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # Největší bezpečné prvočíslo menší než 2**512 + +params = { + "n": 4000055296 * 8 // NUM_BITS, # Velikost datové sady (4 gigabajty); MUSÍ BÝT NÁSOBEK 65536 + "n_inc": 65536, # Přírůstek hodnoty n za období; MUSÍ BÝT NÁSOBEK 65536 + # s epochtime=20000 dává 882 MB ročně + "cache_size": 2500, # Velikost mezipaměti lehkého klienta (může si zvolit lehký klient, není součástí specifikace algoritmu) + "diff": 2**14, # Obtížnost (upraveno během vyhodnocování bloku) + "epochtime": 100000, # Délka epochy v blocích (jak často se datová sada aktualizuje) + "k": 1, # Počet rodičů uzlu + "w": w, # Používá se pro hašování modulárním umocňováním + "accesses": 200, # Počet přístupů k datové sadě během hashimota + "P": SAFE_PRIME_512 # Bezpečné prvočíslo pro hašování a generování náhodných čísel +} +``` + +`P` je v tomto případě prvočíslo zvolené tak, že `log₂(P)` je jen o málo menší než 512, což odpovídá 512 bitům, které jsme používali k reprezentaci našich čísel. Všimněte si, že je třeba ukládat pouze druhou polovinu DAG, takže de-facto požadavek na paměť RAM začíná na 1 GB a roste o 441 MB ročně. + +### Vytvoření grafu Daggeru {#dagger-graph-building} + +Primitivní funkce pro vytvoření grafu Daggeru je definována následovně: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +V podstatě začíná graf jako jediný uzel, `sha3(seed)`, a odtud začne postupně přidávat další uzly na základě náhodných předchozích uzlů. Když je vytvořen nový uzel, je vypočítána modulární mocnina seedu pro náhodný výběr některých indexů menších než `i` (pomocí `x % i` výše) a hodnoty uzlů na těchto indexech jsou použity ve výpočtu pro generování nové hodnoty `x`, která je pak vložena do malé funkce důkazu prací (založené na XOR) pro konečné vygenerování hodnoty grafu na indexu `i`. Důvodem tohoto konkrétního návrhu je vynutit si sekvenční přístup k DAG; další hodnota DAG, ke které se bude přistupovat, nemůže být určena, dokud není známa aktuální hodnota. Nakonec modulární umocňování výsledek dále hašuje. + +Tento algoritmus se opírá o několik výsledků z teorie čísel. Diskuzi naleznete v dodatku níže. + +## Vyhodnocení lehkým klientem {#light-client-evaluation} + +Výše uvedená konstrukce grafu má umožnit rekonstrukci každého uzlu v grafu výpočtem podstromu pouze malého počtu uzlů a vyžaduje pouze malé množství pomocné paměti. Všimněte si, že s k=1 je podstrom pouze řetězcem hodnot vedoucích až k prvnímu prvku v DAG. + +Výpočetní funkce lehkého klienta pro DAG funguje následovně: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +V podstatě se jedná pouze o přepsání výše uvedeného algoritmu, který odstraňuje smyčku výpočtu hodnot pro celý DAG a nahrazuje dřívější vyhledávání uzlů rekurzivním voláním nebo vyhledáváním v mezipaměti. Všimněte si, že pro `k=1` je mezipaměť zbytečná, ačkoliv další optimalizace ve skutečnosti předpočítává prvních několik tisíc hodnot DAG a ponechává je jako statickou mezipaměť pro výpočty; implementaci tohoto kódu naleznete v dodatku. + +## Dvojitá vyrovnávací paměť DAG {#double-buffer} + +V plnohodnotném klientovi se používá [_dvojitá vyrovnávací paměť_](https://wikipedia.org/wiki/Multiple_buffering) 2 DAGů vytvořených podle výše uvedeného vzorce. Myšlenka je taková, že DAG se vytvářejí každých `epochtime` bloků podle výše uvedených parametrů. Místo toho, aby klient používal nejnovější vytvořený DAG, používá ten předchozí. Výhodou je, že to umožňuje nahrazovat DAG v průběhu času, aniž by bylo nutné zahrnout krok, kdy těžaři musí náhle přepočítat všechna data. V opačném případě existuje potenciál pro náhlé dočasné zpomalení zpracování řetězce v pravidelných intervalech a dramatické zvýšení centralizace. Tím vzniká riziko 51% útoku během několika minut před přepočítáním všech dat. + +Algoritmus použitý ke generování sady DAG používaných k výpočtu práce pro blok je následující: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # Zadní vyrovnávací paměť není možná, vytvořte pouze přední vyrovnávací paměť + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +Původní myšlenkou Hashimota je použít blockchain jako datovou sadu, provést výpočet, který vybere N indexů z blockchainu, shromáždí transakce na těchto indexech, provede XOR těchto dat a vrátí haš výsledku. Původní algoritmus Thaddeuse Dryji, přeložený do Pythonu pro konzistenci, je následující: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +Bohužel, ačkoli je Hashimoto považováno za paměťově náročné, spoléhá na 256bitovou aritmetiku, která má značnou výpočetní režii. Dagger-Hashimoto však k řešení tohoto problému používá při indexování své datové sady pouze nejméně významných 64 bitů. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +Použití dvojitého SHA3 umožňuje formu předběžného ověření s nulovými daty a téměř okamžitou odezvou, kdy se ověřuje pouze to, že byla poskytnuta správná mezihodnota. Tato vnější vrstva důkazu prací je vysoce přívětivá k ASIC a poměrně slabá, ale existuje proto, aby ještě více ztížila útoky DDoS, protože toto malé množství práce musí být provedeno, aby se vytvořil blok, který nebude okamžitě zamítnut. Zde je verze pro lehkého klienta: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## Těžba a ověřování {#mining-and-verifying} + +Nyní to všechno spojíme do těžebního algoritmu: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +Zde je ověřovací algoritmus: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Ověření přátelské k lehkému klientovi: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Všimněte si také, že Dagger-Hashimoto klade další požadavky na hlavičku bloku: + +- Aby dvouvrstvé ověření fungovalo, musí hlavička bloku obsahovat jak nonce, tak střední hodnotu před hašováním sha3. +- Někde musí hlavička bloku ukládat sha3 aktuální sady seedů. + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Dodatek {#appendix} + +Jak bylo uvedeno výše, RNG použité pro generování DAG se opírá o některé výsledky z teorie čísel. Nejprve poskytneme ujištění, že Lehmerův RNG, který je základem proměnné `picker`, má široké období. Za druhé, ukážeme, že `pow(x,3,P)` nezobrazí `x` na `1` nebo `P-1` za předpokladu, že na začátku je `x ∈ [2,P-2]`. Nakonec ukážeme, že `pow(x,3,P)` má nízkou míru kolizí, pokud je považováno za hašovací funkci. + +### Lehmerův generátor náhodných čísel {#lehmer-random-number} + +Přestože funkce `produce_dag` nemusí produkovat nezaujatá náhodná čísla, potenciální hrozbou je, že `seed**i % P` nabývá pouze několika hodnot. To by mohlo poskytnout výhodu těžařům, kteří vzor rozpoznají, oproti těm, kteří ho nerozpoznají. + +Abychom se tomu vyhnuli, odvoláváme se na výsledek z teorie čísel. [_Bezpečné prvočíslo_](https://en.wikipedia.org/wiki/Safe_prime) je definováno jako prvočíslo `P` takové, že `(P-1)/2` je také prvočíslo. _Řád_ členu `x` [multiplikativní skupiny](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` je definován jako minimální `m` takové, že 
xᵐ mod P ≡ 1
+Vzhledem k těmto definicím máme: + +> Pozorování 1. Nechť `x` je členem multiplikativní skupiny `ℤ/Pℤ` pro bezpečné prvočíslo `P`. Pokud `x mod P ≠ 1 mod P` a `x mod P ≠ P-1 mod P`, pak řád `x` je buď `P-1` nebo `(P-1)/2`. + +_Důkaz_. Protože `P` je bezpečné prvočíslo, pak podle [Lagrangeovy věty][lagrange] máme, že řád `x` je buď `1`, `2`, `(P-1)/2` nebo `P-1`. + +Řád `x` nemůže být `1`, protože podle Malé Fermatovy věty máme: + +
xP-1 mod P ≡ 1
+ +Proto musí být `x` multiplikativní identitou `ℤ/nℤ`, která je jedinečná. Protože jsme předpokládali, že `x ≠ 1`, není to možné. + +Řád `x` nemůže být `2`, pokud `x ≠ P-1`, protože by to porušilo, že `P` je prvočíslo. + +Z výše uvedeného tvrzení můžeme rozpoznat, že iterace `(picker * init) % P` bude mít délku cyklu alespoň `(P-1)/2`. Je to proto, že jsme zvolili `P` jako bezpečné prvočíslo přibližně rovné vyšší mocnině dvou a `init` je v intervalu `[2,2**256+1]`. Vzhledem k velikosti `P` bychom nikdy neměli očekávat cyklus z modulárního umocňování. + +Když přiřazujeme první buňku v DAG (proměnná označená `init`), vypočítáme `pow(sha3(seed) + 2, 3, P)`. Na první pohled to nezaručuje, že výsledek nebude ani `1`, ani `P-1`. Protože je však `P-1` bezpečné prvočíslo, máme následující další ujištění, které je důsledkem Pozorování 1: + +> Pozorování 2. Nechť `x` je členem multiplikativní skupiny `ℤ/Pℤ` pro bezpečné prvočíslo `P` a nechť `w` je přirozené číslo. Pokud `x mod P ≠ 1 mod P` a `x mod P ≠ P-1 mod P`, a také `w mod P ≠ P-1 mod P` a `w mod P ≠ 0 mod P`, pak `xʷ mod P ≠ 1 mod P` a `xʷ mod P ≠ P-1 mod P` + +### Modulární umocňování jako hašovací funkce {#modular-exponentiation} + +Pro určité hodnoty `P` a `w` může mít funkce `pow(x, w, P)` mnoho kolizí. Například `pow(x,9,19)` nabývá pouze hodnot `{1,18}`. + +Vzhledem k tomu, že `P` je prvočíslo, lze pomocí následujícího výsledku zvolit vhodné `w` pro hašovací funkci modulárního umocňování: + +> Pozorování 3. Nechť `P` je prvočíslo; `w` a `P-1` jsou nesoudělná právě tehdy, když pro všechna `a` a `b` v `ℤ/Pℤ` platí:
`aʷ mod P ≡ bʷ mod P` právě tehdy, když `a mod P ≡ b mod P`
+ +Vzhledem k tomu, že `P` je prvočíslo a `w` je nesoudělné s `P-1`, máme tedy `|{pow(x, w, P) : x ∈ ℤ}| = P`, z čehož vyplývá, že hašovací funkce má nejmenší možnou míru kolizí. + +Ve zvláštním případě, že `P` je bezpečné prvočíslo, jak jsme si zvolili, pak `P-1` má pouze dělitele 1, 2, `(P-1)/2` a `P-1`. Protože `P` > 7, víme, že 3 je nesoudělné s `P-1`, a proto `w=3` splňuje výše uvedené tvrzení. + +## Efektivnější algoritmus vyhodnocování založený na mezipaměti {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..ec0f21a36c1 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1019 @@ +--- +title: Ethash +description: "Podrobný pohled na algoritmus Ethash." +lang: cs +--- + + + + + + Ethash byl algoritmus Etherea pro těžbu s důkazem prací. Důkaz prací byl nyní **zcela vypnut** a Ethereum je místo toho zabezpečeno pomocí [důkazu podílem](/developers/docs/consensus-mechanisms/pos/). Přečtěte si více o [Sloučení](/roadmap/merge/), [důkazu podílem](/developers/docs/consensus-mechanisms/pos/) a [uzamčení](/staking/). Tato stránka má pouze historickou hodnotu! + + + + +Ethash je upravená verze algoritmu [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). Důkaz prací Ethash je [paměťově náročný](https://wikipedia.org/wiki/Memory-hard_function), díky čemuž se předpokládalo, že je algoritmus odolný vůči ASIC. Nakonec byly vyvinuty ASIC pro Ethash, ale těžba pomocí GPU byla stále reálnou možností, dokud nebyl vypnut důkaz prací. Ethash se stále používá k těžbě jiných coinů na jiných ne-ethereových sítích s důkazem prací. + +## Jak Ethash funguje? {#how-does-ethash-work} + +Paměťové náročnosti je dosaženo pomocí algoritmu důkazu prací, který vyžaduje výběr podmnožin z pevně daného zdroje v závislosti na nonce a hlavičce bloku. Tento zdroj (o velikosti několika gigabytů) se nazývá DAG. DAG se mění každých 30 000 bloků, což je ~125hodinové okno nazývané epocha (přibližně 5,2 dne), a jeho generování chvíli trvá. Protože DAG závisí pouze na výšce bloku, může být předem vygenerován, ale pokud není, musí klient počkat do konce tohoto procesu, aby mohl vytvořit blok. Pokud klienti negenerují a neukládají DAGy do mezipaměti předem, může na síti docházet k masivnímu zpoždění bloků při každém přechodu epochy. Všimněte si, že DAG nemusí být generován pro ověření důkazu prací, což v podstatě umožňuje ověření s nízkým využitím CPU a malou pamětí. + +Obecný postup, který algoritmus používá, je následující: + +1. Existuje **seed**, který lze vypočítat pro každý blok proskenováním hlaviček bloků až do daného bodu. +2. Ze seedu lze vypočítat **16MB pseudonáhodnou mezipaměť**. Lehcí klienti ukládají mezipaměť. +3. Z mezipaměti můžeme vygenerovat **1GB datovou sadu** s vlastností, že každá položka v datové sadě závisí pouze na malém počtu položek z mezipaměti. Plní klienti a těžaři ukládají datovou sadu. Datová sada roste lineárně s časem. +4. Těžba zahrnuje získávání náhodných výřezů z datové sady a jejich společné hašování. Ověření lze provést s malou pamětí použitím mezipaměti k regeneraci specifických částí datové sady, které potřebujete, takže stačí ukládat pouze mezipaměť. + +Velká datová sada se aktualizuje jednou za 30 000 bloků, takže drtivá většina úsilí těžaře bude spočívat ve čtení datové sady, nikoli v jejích změnách. + +## Definice {#definitions} + +Používáme následující definice: + +``` +WORD_BYTES = 4 # bajtů ve slově +DATASET_BYTES_INIT = 2**30 # bajtů v datové sadě při genezi +DATASET_BYTES_GROWTH = 2**23 # růst datové sady za epochu +CACHE_BYTES_INIT = 2**24 # bajtů v mezipaměti při genezi +CACHE_BYTES_GROWTH = 2**17 # růst mezipaměti za epochu +CACHE_MULTIPLIER=1024 # Velikost DAG relativně k mezipaměti +EPOCH_LENGTH = 30000 # bloků za epochu +MIX_BYTES = 128 # šířka mixu +HASH_BYTES = 64 # délka haše v bajtech +DATASET_PARENTS = 256 # počet rodičů každého prvku datové sady +CACHE_ROUNDS = 3 # počet kol při produkci mezipaměti +ACCESSES = 64 # počet přístupů ve smyčce hashimoto +``` + +### Použití 'SHA3' {#sha3} + +Vývoj Etherea se shodoval s vývojem standardu SHA3 a v procesu standardizace došlo k pozdní změně ve výplni finalizovaného hašovacího algoritmu, takže ethereové haše \"sha3_256\" a \"sha3_512\" nejsou standardními haši sha3, ale variantou, která je v jiných kontextech často označována jako \"Keccak-256\" a \"Keccak-512\". Viz diskuse, např. [zde](https://eips.ethereum.org/EIPS/eip-1803), [zde](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), nebo [zde](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +Mějte to prosím na paměti, jelikož se na haše \"sha3\" odkazuje v níže uvedeném popisu algoritmu. + +## Parametry {#parameters} + +Parametry pro mezipaměť a datovou sadu Ethashe závisí na čísle bloku. Velikost mezipaměti i velikost datové sady rostou lineárně; nicméně vždy bereme nejvyšší prvočíslo pod lineárně rostoucí prahovou hodnotou, abychom snížili riziko náhodných pravidelností vedoucích k cyklickému chování. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +Tabulky hodnot velikosti datové sady a mezipaměti jsou uvedeny v příloze. + +## Generování mezipaměti {#cache-generation} + +Nyní specifikujeme funkci pro vytvoření mezipaměti: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # Sekvenčně vytvoří počáteční datovou sadu + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # Použije verzi randmemohash s nízkým počtem kol + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +Proces produkce mezipaměti zahrnuje nejprve sekvenční zaplnění 32 MB paměti, poté provedení dvou průchodů algoritmu _RandMemoHash_ Sergia Demiana Lernera z práce [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Výstupem je sada 524 288 64bajtových hodnot. + +## Funkce agregace dat {#date-aggregation-function} + +V některých případech používáme algoritmus inspirovaný [hašem FNV](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) jako neasociativní náhradu za XOR. Všimněte si, že prvočíslo násobíme celým 32bitovým vstupem, na rozdíl od specifikace FNV-1, která postupně násobí prvočíslo jedním bajtem (oktetem). + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +Upozorňujeme, že i když yellow paper (žlutá kniha) specifikuje fnv jako v1\*(FNV_PRIME ^ v2), všechny současné implementace konzistentně používají výše uvedenou definici. + +## Výpočet plné datové sady {#full-dataset-calculation} + +Každá 64bajtová položka v plné 1GB datové sadě se vypočítá následovně: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # inicializace mixu + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # fnv s mnoha náhodnými uzly mezipaměti na základě i + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +V podstatě kombinujeme data z 256 pseudonáhodně vybraných uzlů mezipaměti a hašujeme je, abychom vypočítali uzel datové sady. Celá datová sada je pak generována pomocí: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## Hlavní smyčka {#main-loop} + +Nyní specifikujeme hlavní smyčku podobnou \"hashimoto\", kde agregujeme data z plné datové sady, abychom vytvořili naši konečnou hodnotu pro konkrétní hlavičku a nonce. V níže uvedeném kódu `header` představuje _haš_ SHA3-256 reprezentace RLP _zkrácené_ hlavičky bloku, tj. hlavičky s vyloučením polí **mixHash** a **nonce**. `nonce` je osm bajtů 64bitového celého čísla bez znaménka v pořadí big-endian. Takže `nonce[::-1]` je osmibajtová reprezentace této hodnoty v pořadí little-endian: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # zkombinuje header+nonce do 64bajtového seedu + s = sha3_512(header + nonce[::-1]) + # spustí mix s replikovaným s + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # přimíchá náhodné uzly datové sady + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # komprimuje mix + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +V podstatě udržujeme \"mix\" o šířce 128 bajtů a opakovaně sekvenčně načítáme 128 bajtů z plné datové sady a používáme funkci `fnv` ke zkombinování s mixem. Používá se 128 bajtů sekvenčního přístupu, takže každé kolo algoritmu vždy načte celou stránku z paměti RAM, čímž se minimalizují chyby v translation lookaside bufferu (vyrovnávací paměti pro překlad adres), kterým by se teoreticky mohly vyhnout ASIC. + +Pokud je výstup tohoto algoritmu pod požadovaným cílem, pak je nonce platný. Všimněte si, že dodatečná aplikace `sha3_256` na konci zajišťuje, že existuje mezilehlý nonce, který lze poskytnout k prokázání, že byla vykonána alespoň malá část práce; toto rychlé vnější ověření PoW lze použít pro účely anti-DDoS. Slouží také k poskytnutí statistické jistoty, že výsledek je nezaujaté 256bitové číslo. + +## Těžba {#mining} + +Algoritmus těžby je definován následovně: + +```python +def mine(full_size, dataset, header, difficulty): + # vyplní cíl nulami pro porovnání s hašem na stejné číslici + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## Definování seed haše {#seed-hash} + +K výpočtu seed haše, který by byl použit k těžbě na daném bloku, používáme následující algoritmus: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +Všimněte si, že pro plynulou těžbu a ověřování doporučujeme předem vypočítat budoucí seedhaše a datové sady v samostatném vlákně. + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Dodatek {#appendix} + +Následující kód by měl být připojen na začátek, pokud máte zájem spustit výše uvedenou specifikaci v Pythonu jako kód. + +```python +import sha3, copy + +# Předpokládá pořadí bitů little endian (stejné jako u architektur Intel) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# hašovací funkce sha3, výstupem je 64 bajtů +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### Velikosti dat {#data-sizes} + +Následující vyhledávací tabulky poskytují přibližně 2048 tabelovaných epoch velikostí dat a velikostí mezipaměti. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 180092608, 180223808, 180354752, +180485696, 180617152, 180748096, 180877504, 181009984, 181139264, +181272512, 181402688, 181532608, 181663168, 181795136, 181926592, +182057536, 182190016, 182320192, 182451904, 182582336, 182713792, +182843072, 182976064, 183107264, 183237056, 183368384, 183494848, +183631424, 183762752, 183893824, 184024768, 184154816, 184286656, +184417984, 184548928, 184680128, 184810816, 184941248, 185072704, +185203904, 185335616, 185465408, 185596352, 185727296, 185859904, +185989696, 186121664, 186252992, 186383552, 186514112, 186645952, +186777152, 186907328, 187037504, 187170112, 187301824, 187429184, +187562048, 187693504, 187825472, 187957184, 188087104, 188218304, +188349376, 188481344, 188609728, 188743616, 188874304, 189005248, +189136448, 189265088, 189396544, 189528128, 189660992, 189791936, +189923264, 190054208, 190182848, 190315072, 190447424, 190577984, +190709312, 190840768, 190971328, 191102656, 191233472, 191364032, +191495872, 191626816, 191758016, 191888192, 192020288, 192148928, +192282176, 192413504, 192542528, 192674752, 192805952, 192937792, +193068608, 193198912, 193330496, 193462208, 193592384, 193723456, +193854272, 193985984, 194116672, 194247232, 194379712, 194508352, +194641856, 194772544, 194900672, 195035072, 195166016, 195296704, +195428032, 195558592, 195690304, 195818176, 195952576, 196083392, +196214336, 196345792, 196476736, 196607552, 196739008, 196869952, +197000768, 197130688, 197262784, 197394368, 197523904, 197656384, +197787584, 197916608, 198049472, 198180544, 198310208, 198442432, +198573632, 198705088, 198834368, 198967232, 199097792, 199228352, +199360192, 199491392, 199621696, 199751744, 199883968, 200014016, +200146624, 200276672, 200408128, 200540096, 200671168, 200801984, +200933312, 201062464, 201194944, 201326144, 201457472, 201588544, +201719744, 201850816, 201981632, 202111552, 202244032, 202374464, +202505152, 202636352, 202767808, 202898368, 203030336, 203159872, +203292608, 203423296, 203553472, 203685824, 203816896, 203947712, +204078272, 204208192, 204341056, 204472256, 204603328, 204733888, +204864448, 204996544, 205125568, 205258304, 205388864, 205517632, +205650112, 205782208, 205913536, 206044736, 206176192, 206307008, +206434496, 206569024, 206700224, 206831168, 206961856, 207093056, +207223616, 207355328, 207486784, 207616832, 207749056, 207879104, +208010048, 208141888, 208273216, 208404032, 208534336, 208666048, +208796864, 208927424, 209059264, 209189824, 209321792, 209451584, +209582656, 209715136, 209845568, 209976896, 210106432, 210239296, +210370112, 210501568, 210630976, 210763712, 210894272, 211024832, +211156672, 211287616, 211418176, 211549376, 211679296, 211812032, +211942592, 212074432, 212204864, 212334016, 212467648, 212597824, +212727616, 212860352, 212991424, 213120832, 213253952, 213385024, +213515584, 213645632, 213777728, 213909184, 214040128, 214170688, +214302656, 214433728, 214564544, 214695232, 214826048, 214956992, +215089088, 215219776, 215350592, 215482304, 215613248, 215743552, +215874752, 216005312, 216137024, 216267328, 216399296, 216530752, +216661696, 216790592, 216923968, 217054528, 217183168, 217316672, +217448128, 217579072, 217709504, 217838912, 217972672, 218102848, +218233024, 218364736, 218496832, 218627776, 218759104, 218888896, +219021248, 219151936, 219281728, 219413056, 219545024, 219675968, +219807296, 219938624, 220069312, 220200128, 220331456, 220461632, +220592704, 220725184, 220855744, 220987072, 221117888, 221249216, +221378368, 221510336, 221642048, 221772736, 221904832, 222031808, +222166976, 222297536, 222428992, 222559936, 222690368, 222820672, +222953152, 223083968, 223213376, 223345984, 223476928, 223608512, +223738688, 223869376, 224001472, 224132672, 224262848, 224394944, +224524864, 224657344, 224788288, 224919488, 225050432, 225181504, +225312704, 225443776, 225574592, 225704768, 225834176, 225966784, +226097216, 226229824, 226360384, 226491712, 226623424, 226754368, +226885312, 227015104, 227147456, 227278528, 227409472, 227539904, +227669696, 227802944, 227932352, 228065216, 228196288, 228326464, +228457792, 228588736, 228720064, 228850112, 228981056, 229113152, +229243328, 229375936, 229505344, 229636928, 229769152, 229894976, +230030272, 230162368, 230292416, 230424512, 230553152, 230684864, +230816704, 230948416, 231079616, 231210944, 231342016, 231472448, +231603776, 231733952, 231866176, 231996736, 232127296, 232259392, +232388672, 232521664, 232652608, 232782272, 232914496, 233043904, +233175616, 233306816, 233438528, 233569984, 233699776, 233830592, +233962688, 234092224, 234221888, 234353984, 234485312, 234618304, +234749888, 234880832, 235011776, 235142464, 235274048, 235403456, +235535936, 235667392, 235797568, 235928768, 236057152, 236190272, +236322752, 236453312, 236583616, 236715712, 236846528, 236976448, +237108544, 237239104, 237371072, 237501632, 237630784, 237764416, +237895232, 238026688, 238157632, 238286912, 238419392, 238548032, +238681024, 238812608, 238941632, 239075008, 239206336, 239335232, +239466944, 239599168, 239730496, 239861312, 239992384, 240122816, +240254656, 240385856, 240516928, 240647872, 240779072, 240909632, +241040704, 241171904, 241302848, 241433408, 241565248, 241696192, +241825984, 241958848, 242088256, 242220224, 242352064, 242481856, +242611648, 242744896, 242876224, 243005632, 243138496, 243268672, +243400384, 243531712, 243662656, 243793856, 243924544, 244054592, +244187072, 244316608, 244448704, 244580032, 244710976, 244841536, +244972864, 245104448, 245233984, 245365312, 245497792, 245628736, +245759936, 245889856, 246021056, 246152512, 246284224, 246415168, +246545344, 246675904, 246808384, 246939584, 247070144, 247199552, +247331648, 247463872, 247593536, 247726016, 247857088, 247987648, +248116928, 248249536, 248380736, 248512064, 248643008, 248773312, +248901056, 249036608, 249167552, 249298624, 249429184, 249560512, +249692096, 249822784, 249954112, 250085312, 250215488, 250345792, +250478528, 250608704, 250739264, 250870976, 251002816, 251133632, +251263552, 251395136, 251523904, 251657792, 251789248, 251919424, +252051392, 252182464, 252313408, 252444224, 252575552, 252706624, +252836032, 252968512, 253099712, 253227584, 253361728, 253493056, +253623488, 253754432, 253885504, 254017216, 254148032, 254279488, +254410432, 254541376, 254672576, 254803264, 254933824, 255065792, +255196736, 255326528, 255458752, 255589952, 255721408, 255851072, +255983296, 256114624, 256244416, 256374208, 256507712, 256636096, +256768832, 256900544, 257031616, 257162176, 257294272, 257424448, +257555776, 257686976, 257818432, 257949632, 258079552, 258211136, +258342464, 258473408, 258603712, 258734656, 258867008, 258996544, +259127744, 259260224, 259391296, 259522112, 259651904, 259784384, +259915328, 260045888, 260175424, 260308544, 260438336, 260570944, +260700992, 260832448, 260963776, 261092672, 261226304, 261356864, +261487936, 261619648, 261750592, 261879872, 262011968, 262143424, +262274752, 262404416, 262537024, 262667968, 262799296, 262928704, +263061184, 263191744, 263322944, 263454656, 263585216, 263716672, +263847872, 263978944, 264108608, 264241088, 264371648, 264501184, +264632768, 264764096, 264895936, 265024576, 265158464, 265287488, +265418432, 265550528, 265681216, 265813312, 265943488, 266075968, +266206144, 266337728, 266468032, 266600384, 266731072, 266862272, +266993344, 267124288, 267255616, 267386432, 267516992, 267648704, +267777728, 267910592, 268040512, 268172096, 268302784, 268435264, +268566208, 268696256, 268828096, 268959296, 269090368, 269221312, +269352256, 269482688, 269614784, 269745856, 269876416, 270007616, +270139328, 270270272, 270401216, 270531904, 270663616, 270791744, +270924736, 271056832, 271186112, 271317184, 271449536, 271580992, +271711936, 271843136, 271973056, 272105408, 272236352, 272367296, +272498368, 272629568, 272759488, 272891456, 273022784, 273153856, +273284672, 273415616, 273547072, 273677632, 273808448, 273937088, +274071488, 274200896, 274332992, 274463296, 274595392, 274726208, +274857536, 274988992, 275118656, 275250496, 275382208, 275513024, +275643968, 275775296, 275906368, 276037184, 276167872, 276297664, +276429376, 276560576, 276692672, 276822976, 276955072, 277085632, +277216832, 277347008, 277478848, 277609664, 277740992, 277868608, +278002624, 278134336, 278265536, 278395328, 278526784, 278657728, +278789824, 278921152, 279052096, 279182912, 279313088, 279443776, +279576256, 279706048, 279838528, 279969728, 280099648, 280230976, +280361408, 280493632, 280622528, 280755392, 280887104, 281018176, +281147968, 281278912, 281411392, 281542592, 281673152, 281803712, +281935552, 282066496, 282197312, 282329024, 282458816, 282590272, +282720832, 282853184, 282983744, 283115072, 283246144, 283377344, +283508416, 283639744, 283770304, 283901504, 284032576, 284163136, +284294848, 284426176, 284556992, 284687296, 284819264, 284950208, +285081536] +``` diff --git a/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..707392b17b8 --- /dev/null +++ b/public/content/translations/cs/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "Těžební algoritmy" +description: "Podrobný pohled na algoritmy používané pro těžbu Etherea." +lang: cs +--- + + + + + +Proof-of-work již není základním mechanismem konsensu Etherea, což znamená, že těžení bylo vypnuto. Místo toho je Ethereum zabezpečeno validátory, kteří stakují ETH. Své ETH můžete začít stakeovat hned dnes. Přečtěte si více o Sloučení, proof-of-stake a stakování. Tato stránka má pouze historický význam. + + + + +Těžba Etherea používala algoritmus známý jako Ethash. Základní myšlenkou algoritmu je, že se těžař snaží najít vstupní nonce pomocí výpočtu hrubou silou tak, aby výsledný haš byl menší než prahová hodnota určená vypočítanou obtížností. Tuto úroveň obtížnosti lze dynamicky upravovat, což umožňuje, aby produkce bloků probíhala v pravidelném intervalu. + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky vám doporučujeme si nejprve přečíst o [konsensu proof-of-work](/developers/docs/consensus-mechanisms/pow) a [těžbě](/developers/docs/consensus-mechanisms/pow/mining). + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto byl předběžný výzkumný algoritmus pro těžbu Etherea, který nahradil Ethash. Jednalo se o spojení dvou různých algoritmů: Dagger a Hashimoto. Šlo pouze o výzkumnou implementaci, která byla v době spuštění mainnetu Etherea nahrazena algoritmem Ethash. + +[Dagger](http://www.hashcash.org/papers/dagger.html) zahrnuje generování [orientovaného acyklického grafu](https://en.wikipedia.org/wiki/Directed_acyclic_graph), jehož náhodné části se společně hašují. Základním principem je, že každá nonce vyžaduje pouze malou část velkého celkového datového stromu. Přepočítávání podstromu pro každou nonce je pro těžbu neúnosné – proto je nutné strom uložit –, ale pro ověření jediné hodnoty nonce je to v pořádku. Dagger byl navržen jako alternativa ke stávajícím algoritmům, jako je Scrypt, které jsou paměťově náročné (memory-hard), ale obtížně se ověřují, když se jejich paměťová náročnost zvýší na skutečně bezpečnou úroveň. Dagger byl však zranitelný vůči hardwarové akceleraci sdílené paměti a bylo od něj upuštěno ve prospěch jiných směrů výzkumu. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) je algoritmus, který přidává odolnost vůči ASIC tím, že je vázán na I/O (vstup/výstup) (tj. čtení z paměti je limitujícím faktorem v procesu těžby). Teorie je taková, že paměť RAM je dostupnější než výpočetní výkon; výzkum v hodnotě miliard dolarů se již zabýval optimalizací paměti RAM pro různé případy použití, které často zahrnují téměř náhodné vzory přístupu (odtud „paměť s náhodným přístupem“). V důsledku toho je stávající paměť RAM pravděpodobně poměrně blízko optimu pro vyhodnocování algoritmu. Hashimoto používá blockchain jako zdroj dat a současně splňuje body (1) a (3) uvedené výše. + +Dagger-Hashimoto používal upravené verze algoritmů Dagger a Hashimoto. Rozdíl mezi Dagger Hashimoto a Hashimoto je v tom, že namísto použití blockchainu jako zdroje dat používá Dagger Hashimoto vlastní vygenerovanou datovou sadu, která se aktualizuje na základě dat bloku každých N bloků. Datová sada se generuje pomocí algoritmu Dagger, což umožňuje efektivní výpočet podmnožiny specifické pro každou nonce pro ověřovací algoritmus lehkého klienta. Rozdíl mezi algoritmy Dagger Hashimoto a Dagger je v tom, že na rozdíl od původního Daggeru je datová sada používaná k dotazování bloku semipermanentní a aktualizuje se pouze v občasných intervalech (např. jednou týdně). To znamená, že část úsilí vynaloženého na generování datové sady se blíží nule, takže argumenty Sergia Lernera ohledně zrychlení díky sdílené paměti se stávají zanedbatelnými. + +Více o [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). + +## Ethash {#ethash} + +Ethash byl těžební algoritmus, který se skutečně používal na mainnetu Etherea v rámci dnes již zastaralé architektury proof-of-work. Ethash byl v podstatě nový název pro specifickou verzi Dagger-Hashimoto poté, co byl algoritmus výrazně aktualizován, přičemž si stále zachoval základní principy svého předchůdce. Mainnet Etherea používal pouze Ethash – Dagger Hashimoto byl verzí těžebního algoritmu pro výzkum a vývoj, která byla nahrazena předtím, než začala těžba na mainnetu Etherea. + +Více o [Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ diff --git a/public/content/translations/cs/developers/docs/dapps/index.md b/public/content/translations/cs/developers/docs/dapps/index.md index 4687126396f..6282fea3291 100644 --- a/public/content/translations/cs/developers/docs/dapps/index.md +++ b/public/content/translations/cs/developers/docs/dapps/index.md @@ -1,64 +1,64 @@ --- -title: Úvod do dappek +title: "Technický úvod do dapps" description: lang: cs --- -Decentralizovaná aplikace (dappka) je aplikace naprogramovaná na decentralizované síti, která kombinuje [chytrý kontrakt](/developers/docs/smart-contracts/) a frontendové uživatelské rozhraní. V Ethereu jsou chytré kontrakty přístupné a transparentní jako otevřené API, takže vaše dappka může obsahovat i chytrý kontrakt, který napsal někdo jiný. +Decentralizovaná aplikace (dapp) je aplikace vytvořená na decentralizované síti, která kombinuje [chytrý kontrakt](/developers/docs/smart-contracts/) a frontendové uživatelské rozhraní. V Ethereu jsou chytré kontrakty přístupné a transparentní jako otevřené API, takže vaše dappka může obsahovat i chytrý kontrakt, který napsal někdo jiný. ## Předpoklady {#prerequisites} -Než se začnete učit o dappkách, měli byste se seznámit se[ základy blockchainu](/developers/docs/intro-to-ethereum/) a přečíst si něco o síti Ethereu a o její decentralizaci. +Než se začnete učit o dapps, měli byste se seznámit se [základy blockchainu](/developers/docs/intro-to-ethereum/) a přečíst si o síti Ethereum a její decentralizaci. -## Definice dappky {#definition-of-a-dapp} +## Definice dapp {#definition-of-a-dapp} Dappka má svůj backendový kód spuštěný v decentralizované peer-to-peer síti. To je v kontrastu s aplikací, jejíž backendový kód běží na centralizovaných serverech. -Dappka může mít frontendový kód a uživatelská rozhraní napsaná v libovolném programovacím jazyce (stejně jako aplikace), který může volat její backend. Kromě toho může být její frontend umístěn na decentralizovaném úložišti, jako je [IPFS](https://ipfs.io/). +Dappka může mít frontendový kód a uživatelská rozhraní napsaná v libovolném programovacím jazyce (stejně jako aplikace), který může volat její backend. Kromě toho může být její frontend hostován na decentralizovaném úložišti, jako je [IPFS](https://ipfs.io/). -- **Decentralizované** – dappky fungují na Ethereu, otevřené veřejné decentralizované platformě, nad kterou nemá kontrolu žádná jednotlivá osoba ani skupina. -- **Deterministické** – dappky vykonávají stejnou funkci bez ohledu na prostředí, ve kterém jsou spuštěny. -- **Turingovsky úplné** – dappky mohou provádět jakoukoliv akci, pokud mají k dispozici potřebné prostředky. -- **Izolované** – dappky jsou spouštěny ve virtuálním prostředí známém jako Virtuální stroj Etherea, takže pokud chytrý kontrakt obsahuje nějakou chybu, neovlivní to běžné fungování blockchainové sítě. +- **Decentralizované** – dapps fungují na Ethereu, otevřené veřejné decentralizované platformě, nad kterou nemá kontrolu žádná osoba ani skupina. +- **Deterministické** – dapps vykonávají stejnou funkci bez ohledu na prostředí, ve kterém jsou spuštěny. +- **Turingovsky úplné** – dapps mohou provádět jakoukoli akci, pokud mají k dispozici potřebné prostředky. +- **Izolované** – dapps jsou spouštěny ve virtuálním prostředí známém jako Ethereum Virtual Machine (EVM), takže pokud má chytrý kontrakt chybu, neovlivní to běžné fungování blockchainové sítě. ### O chytrých kontraktech {#on-smart-contracts} -Abychom mohli vysvětlit fungování dappek, musíme nejdříve vysvětlit chytré kontrakty – backend dappek, což není úplně přesné, ale lepší popis neexistuje. Podrobný přehled naleznete v sekci o [chytrých kontraktech](/developers/docs/smart-contracts/). +Abychom mohli vysvětlit fungování dappek, musíme nejdříve vysvětlit chytré kontrakty – backend dappek, což není úplně přesné, ale lepší popis neexistuje. Podrobný přehled naleznete v naší sekci o [chytrých kontraktech](/developers/docs/smart-contracts/). Chytrý kontrakt je kód, který žije v blockchainu Etherea a běží přesně tak, jak je naprogramován. Jakmile jsou chytré kontrakty spuštěny na síti, nemůžete je měnit. Dappky mohou být decentralizované, protože jsou řízeny logikou zapsanou do kontraktu, nikoli jednotlivcem nebo společností. To také znamená, že musíte své kontrakty navrhovat velmi pečlivě a důkladně je testovat. -## Výhody vývoje dappek {#benefits-of-dapp-development} +## Výhody vývoje dapps {#benefits-of-dapp-development} -- **Žádné výpadky** – Jakmile je chytrý kontrakt umístěn na blockchain a spuštěn, síť jako celek bude vždy schopna vyhovět uživatelům, kteří chtějí s kontraktem komunikovat. Zlomyslní aktéři proto nemohou provádět útoky typu DoS zaměřené na jednotlivé dappky. -- **Soukromí** – K nasazení dappky nebo interakci s ní není třeba zveřejnit svoji skutečnou identitu. -- **Odolnost vůči cenzuře** – Žádný subjekt v síti nemůže uživatelům blokovat zadávání transakcí, nasazování dappek nebo čtení dat z blockchainu. +- **Žádné výpadky** – Jakmile je chytrý kontrakt nasazen na blockchain, síť jako celek bude vždy schopna obsloužit klienty, kteří chtějí s kontraktem interagovat. Zlomyslní aktéři proto nemohou provádět útoky typu DoS zaměřené na jednotlivé dappky. +- **Soukromí** – K nasazení dapp nebo interakci s ní nemusíte poskytovat svou skutečnou identitu. +- **Odolnost vůči cenzuře** – Žádný subjekt v síti nemůže uživatelům blokovat odesílání transakcí, nasazování dapps nebo čtení dat z blockchainu. - **Úplná integrita dat** – Data uložená na blockchainu jsou díky kryptografickým primitivům neměnná a nezpochybnitelná. Zlomyslní aktéři nemohou falšovat transakce ani jiná data, která již byla zveřejněna. -- **Výpočty / ověřitelné chování bez nutnosti důvěry** – Chytré kontrakty lze analyzovat a je zaručeno, že se budou provádět předvídatelně, aniž by bylo nutné důvěřovat nějaké centrální autoritě. To v tradičních modelech neplatí. Např. když používáme systémy internetového bankovnictví, musíme věřit, že finanční instituce nezneužijí naše finanční údaje, nezmanipulují záznamy nebo se do nich nenabourají hackeři. +- **Výpočty bez nutnosti důvěry / ověřitelné chování** – Chytré kontrakty lze analyzovat a je zaručeno, že se budou provádět předvídatelným způsobem, aniž by bylo nutné důvěřovat centrální autoritě. To v tradičních modelech neplatí. Např. když používáme systémy internetového bankovnictví, musíme věřit, že finanční instituce nezneužijí naše finanční údaje, nezmanipulují záznamy nebo se do nich nenabourají hackeři. -## Nevýhody vývoje dappek {#drawbacks-of-dapp-development} +## Nevýhody vývoje dapps {#drawbacks-of-dapp-development} -- **Údržba** – Údržba dappek je náročnější, protože kód a data publikovaná na blockchainu se hůře upravují. Pro vývojáře je těžké aktualizovat dappky (nebo podkladová data, která dappky ukládají), jakmile jsou nasazeny, když jsou ve staré verzi identifikovány chyby nebo bezpečnostní rizika. -- **Výkonnostní režie** – Výkonnostní režie je obrovská a škálování je opravdu obtížné. Aby bylo dosaženo úrovně bezpečnosti, integrity, transparentnosti a spolehlivosti, o kterou Ethereum usiluje, musí každý uzel spouštět a ukládat každou transakci. Kromě toho, nějaký čas zabere i konsenzus důkazu podílem. -- **Přetížení sítě** – Pokud jedna dappka využívá příliš mnoho výpočetních zdrojů, celá síť se zahltí. V současné době je síť schopna zpracovat pouze asi 10–15 transakcí za sekundu. Pokud jsou transakce odesílány rychleji, může fond nepotvrzených transakcí rychle narůstat. -- **Uživatelská zkušenost** – Může být obtížnější navrhnout uživatelsky přívětivé prostředí, protože průměrný koncový uživatel by mohl považovat za příliš složité nastavit nástrojový stack nezbytný pro skutečně bezpečnou interakci s blockchainem. -- **Centralizace** – Uživatelsky a vývojářsky přívětivá řešení spuštěná na základní vrstvě Etherea mohou nakonec vypadat jako centralizované služby. Např. takové služby mohou ukládat klíče nebo jiné citlivé informace na serverové straně, poskytovat frontend pomocí centralizovaného serveru nebo provozovat důležitou obchodní logiku na centralizovaném serveru před zápisem na blockchain. Centralizace eliminuje mnoho (ne-li všechny) výhod blockchainu oproti tradičnímu modelu. +- **Údržba** – Udržovat dapps může být těžší, protože kód a data publikovaná na blockchainu se hůře upravují. Pro vývojáře je těžké aktualizovat dappky (nebo podkladová data, která dappky ukládají), jakmile jsou nasazeny, když jsou ve staré verzi identifikovány chyby nebo bezpečnostní rizika. +- **Výkonnostní režie** – Existuje obrovská výkonnostní režie a škálování je opravdu obtížné. Aby bylo dosaženo úrovně bezpečnosti, integrity, transparentnosti a spolehlivosti, o kterou Ethereum usiluje, musí každý uzel spouštět a ukládat každou transakci. Kromě toho, nějaký čas zabere i konsenzus důkazu podílem. +- **Přetížení sítě** – Když jedna dapp využívá příliš mnoho výpočetních zdrojů, celá síť se zahltí. V současné době je síť schopna zpracovat pouze asi 10–15 transakcí za sekundu. Pokud jsou transakce odesílány rychleji, může fond nepotvrzených transakcí rychle narůstat. +- **Uživatelská zkušenost** – Může být obtížnější navrhnout uživatelsky přívětivé prostředí, protože průměrný koncový uživatel může považovat za příliš složité nastavit sadu nástrojů nezbytnou pro skutečně bezpečnou interakci s blockchainem. +- **Centralizace** – Uživatelsky a vývojářsky přívětivá řešení postavená na základní vrstvě Etherea mohou nakonec stejně vypadat jako centralizované služby. Např. takové služby mohou ukládat klíče nebo jiné citlivé informace na serverové straně, poskytovat frontend pomocí centralizovaného serveru nebo provozovat důležitou obchodní logiku na centralizovaném serveru před zápisem na blockchain. Centralizace eliminuje mnoho (ne-li všechny) výhod blockchainu oproti tradičnímu modelu. -## Učíte se spíše vizuálně? {#visual-learner} +## Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} -## Nástroje pro vytváření dappek {#dapp-tools} +## Nástroje pro vytváření dapps {#dapp-tools} -**Scaffold-ETH_ – Experimentujte se Solidity pomocí frontendu, který se přizpůsobuje vašemu chytrému kontraktu._** +**Scaffold-ETH _– Rychle experimentujte se Solidity pomocí frontendu, který se přizpůsobí vašemu chytrému kontraktu._** - [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -- [Příkladová dappka](https://punkwallet.io/) +- [Příklad dapp](https://punkwallet.io/) -**Vytvořte ethereovskou appku _– Vytvořte aplikace s podporou Etherea pomocí jednoho příkazu._** +**Create Eth App _– Vytvořte aplikace s podporou Etherea jedním příkazem._** - [GitHub](https://github.com/paulrberg/create-eth-app) -**One Click Dapp_ – FOSS nástroj pro generování frontendů dappek z [ABI](/glossary/#abi)._** +**One Click Dapp _– FOSS nástroj pro generování frontendů pro dapps z [ABI](/glossary/#abi)._** - [oneclickdapp.com](https://oneclickdapp.com) - [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) @@ -68,7 +68,7 @@ Chytrý kontrakt je kód, který žije v blockchainu Etherea a běží přesně - [etherflow.quiknode.io](https://etherflow.quiknode.io/) - [GitHub](https://github.com/abunsen/etherflow) -**thirdweb_ – SDK v každém jazyce, chytré kontrakty, nástroje a infrastruktura pro vývoj web3._** +**thirdweb _– SDK v každém jazyce, chytré kontrakty, nástroje a infrastruktura pro vývoj web3._** - [Domovská stránka](https://thirdweb.com/) - [Dokumentace](https://portal.thirdweb.com/) @@ -80,17 +80,17 @@ Chytrý kontrakt je kód, který žije v blockchainu Etherea a běží přesně - [Dokumentace](https://docs.crossmint.com) - [Discord](https://discord.com/invite/crossmint) -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Prozkoumat dappky](/apps) -- [The Architecture of a Web 3.0 application](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ -- [A 2021 guide to decentralized applications](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) – _LimeChain_ -- [What Are Decentralized Apps?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) – _Gemini_ -- [Popular dapps](https://www.alchemy.com/dapps) – _Alchemy_ +- [Prozkoumejte dapps](/apps) +- [Architektura aplikace Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ +- [Průvodce decentralizovanými aplikacemi pro rok 2021](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [Co jsou decentralizované aplikace?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [Populární dapps](https://www.alchemy.com/dapps) - _Alchemy_ -_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ji!_ +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ ## Související témata {#related-topics} - [Úvod do stacku Etherea](/developers/docs/ethereum-stack/) -- [Vývojářské rámce](/developers/docs/frameworks/) +- [Vývojářské frameworky](/developers/docs/frameworks/) diff --git a/public/content/translations/cs/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/cs/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..4be9b14c9ae --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "Průzkumníci bloků" +description: "Úvod k průzkumníkům bloků, vašeho portálu do světa blockchainových dat, kde můžete vyhledávat informace o transakcích, účtech, kontraktech a dalších." +lang: cs +sidebarDepth: 3 +--- + +Průzkumníci bloků jsou vaším portálem k datům Etherea. Pomocí nich můžete v reálném čase sledovat údaje o blocích, transakcích, validátorech, účtech a dalších on-chain aktivitách. + +## Předpoklady {#prerequisites} + +Měli byste rozumět základním konceptům Etherea, abyste dokázali porozumět údajům, které vám průzkumník bloku poskytne. Začněte s [úvodem do Etherea](/developers/docs/intro-to-ethereum/). + +## Služby {#services} + +- [Etherscan](https://etherscan.io/) -_Dostupné také v čínštině, korejštině, ruštině a japonštině_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_Dostupné také ve španělštině, francouzštině, italštině, nizozemštině, portugalštině, ruštině, čínštině a perštině_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru Block Explorer](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_Dostupné také v čínštině, španělštině, francouzštině, turečtině, ruštině, korejštině a vietnamštině_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## Open-source nástroje {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## Data {#data} + +Ethereum je ze své podstaty transparentní, takže je vše ověřitelné. Průzkumníci bloků poskytují rozhraní pro získání těchto informací. A to jak pro hlavní síť Ethereum, tak pro testovací sítě, pokud tato data potřebujete. Data se dělí na exekuční data a data o konsensu. Exekuční data se vztahují k transakcím, které byly provedeny v konkrétním bloku. Data o konsensu se týkají samotných bloků a validátorů, kteří je navrhli. + +Zde je přehled typů dat, která můžete z průzkumníka bloků získat. + +### Exekuční data {#execution-data} + +Nové bloky jsou přidávány do Etherea každých 12 sekund (pokud navrhovatel bloku nezmešká svou šanci), takže do průzkumníků bloků je přidáván téměř nepřetržitý tok dat. Bloky obsahují spoustu důležitých údajů, které se vám mohou hodit: + +**Standardní data** + +- Výška bloku (Block height) - značí číslo bloku a délku blockchainu (v blocích) při vytvoření aktuálního bloku +- Časová značka (Timestamp) - Čas, kdy byl blok navržen +- Transakce (Transactions) - Počet transakcí zahrnutých v bloku +- Příjemce poplatků (Fee recipient) - Adresa, která obdržela spropitné z transakcí +- Odměna za blok (Block Reward) - Množství ETH udělené validátorovi, který blok navrhl +- Velikost (Size) - Velikost dat v bloku (měřeno v bajtech) +- Využité palivo (Gas used) - Celkový počet jednotek paliva spotřebovaných transakcemi v bloku +- Limit paliva (Gas limit) - Celkové limity paliva nastavené transakcemi v bloku +- Základní poplatek za palivo (Base fee per gas) - Minimální násobitel potřebný pro zařazení transakce do bloku +- Spálené poplatky (Burnt fees) - Množství ETH spálené v bloku +- Extra data (Extra data) - Jakákoli další data, která tvůrce bloku zahrnul + +**Pokročilá data** + +- Hash (Hash) - Kryptografický hash, který představuje hlavičku bloku (jedinečný identifikátor bloku) +- Rodičovský hash (Parent hash) - Hash bloku, který předcházel aktuálnímu bloku +- Kořenový stav (StateRoot) - Kořenový hash Merkle trie, který ukládá celý stav systému + +### Gas {#gas} + +Průzkumníci bloků vám poskytnou nejen údaje o využití paliva v transakcích a blocích, ale někteří vám poskytnou i informace o aktuálních cenách paliva v síti. To vám pomůže pochopit využití sítě, zadávat bezpečné transakce a neutrácet za palivo příliš mnoho. Vyhledejte rozhraní API, která vám pomohou tyto informace dostat do rozhraní vašeho produktu. Specifické údaje pro palivo zahrnují: + +- Odhadované jednotky paliva potřebné pro bezpečnou, ale pomalou transakci (+ odhadovaná cena a doba trvání) +- Odhadované jednotky paliva potřebné pro průměrnou transakci (+ odhadovaná cena a doba trvání) +- Odhadované jednotky paliva potřebné pro rychlou transakci (+ odhadovaná cena a doba trvání) +- Průměrná doba potvrzení na základě ceny paliva +- Kontrakty, které spotřebovávají palivo – jinými slovy populární produkty, které se v síti hodně používají +- Účty, které spotřebovávají nejvíce paliva – jinými slovy častí uživatelé sítě + +### Transakce {#transactions} + +Průzkumníci bloků se stali běžným místem, kde lidé sledují průběh svých transakcí. Je to proto, že úroveň detailů, kterou můžete získat, poskytuje dodatečnou jistotu. Údaje o transakcích zahrnují: + +**Standardní data** + +- Transaction hash - Hash, který se generuje při odeslání transakce +- Stav - Udává, zda je transakce čekající, neúspěšná, nebo úspěšná +- Block - Označuje blok, ve kterém byla transakce zahrnuta +- Timestamp - Čas, kdy byla transakce zahrnuta do bloku navrženého validátorem +- From - Adresa účtu, který transakci odeslal +- To - Adresa příjemce nebo smart kontraktu, se kterým transakce interaguje +- Tokens transferred - Seznam tokenů, které byly v rámci transakce převedeny +- Hodnota - Celková převáděná hodnota ETH +- Transakční poplatek - Částka zaplacená validátorovi za zpracování transakce (vypočítá se jako cena paliva \* množství použitého paliva) + +**Pokročilá data** + +- Gas limit - Maximální počet jednotek paliva, které může tato transakce spotřebovat +- Využité palivo - Skutečné množství jednotek paliva, které transakce spotřebovala +- Cena paliva - Cena stanovená za jednotku paliva +- Nonce - Číslo transakce pro adresu `from` (mějte na paměti, že se začíná od 0, takže nonce `100` by ve skutečnosti byla 101. transakce odeslaná tímto účtem). +- Vstupní data - Veškeré další informace požadované transakcí + +### Účty {#accounts} + +O účtu existuje mnoho dat, ke kterým můžete získat přístup. Proto se často doporučuje používat více účtů, aby nebylo možné snadno zjistit váš majetek a jeho hodnotu. Ve vývoji jsou také další řešení, která umožňují větší soukromí transakcí a aktivit na účtu. Zde jsou však data, která jsou k dispozici o účtech: + +**Uživatelské účty** + +- Adresa účtu - veřejná adresa, na kterou můžete posílat finanční prostředky +- Zůstatek ETH - Množství ETH spojené s daným účtem +- Celková hodnota ETH - Hodnota ETH +- Tokeny - Tokeny spojené s účtem a jejich hodnota +- Historie transakcí - Seznam všech transakcí, kde byl tento účet buď odesílatelem, nebo příjemcem + +**Chytré kontrakty** + +Smart kontrakt účty obsahují všechny údaje, které má uživatelský účet, ale někteří průzkumníci bloků zobrazují navíc i některé informace o kódu. Mezi příklady patří: + +- Tvůrce kontraktu - Adresa, která kontrakt nasadila na Mainnet +- Transakce vytvoření - Transakce, která zahrnovala spuštění na Mainnetu +- Zdrojový kód - Solidity nebo Vyper kód smart kontraktu +- ABI kontraktu - Aplikační binární rozhraní kontraktu - volání, která kontrakt provádí, a data, která přijímá +- Kód vytvoření kontraktu - Zkompilovaný bajtový kód smart kontraktu - vytvoří se při kompilaci smart kontraktu napsaného v Solidity, Vyper apod. +- Události kontraktu - Historie metod volaných ve smart kontraktu – v podstatě způsob, jak zjistit, jak je kontrakt používán a jak často + +### Tokeny {#tokens} + +Tokeny jsou typem kontraktu, takže ponesou podobné údaje jako smart kontrakty. Ale protože mají hodnotu a lze s nimi obchodovat, mají i další datové položky: + +- Typ - Zda se jedná o token ERC-20, ERC-721 nebo jiný standard +- Cena - Pokud se jedná o ERC-20, budou mít aktuální tržní hodnotu +- Tržní kapitalizace - Pokud se jedná o ERC-20, bude u nich uvedena tržní kapitalizace (vypočtená jako cena \* celkové množství) +- Celková zásoba - Počet tokenů v oběhu +- Držitelé - Počet adres, které drží daný token +- Převody - Počet koliktrát byl token převeden mezi účty +- Historie transakcí - Historie všech transakcí zahrnující daný token +- Adresa kontraktu - Adresa tokenu nasazeného na Mainnet +- Desetinná místa - Tokeny ERC-20 jsou dělitelné a mají desetinná místa + +### Síť {#network} + +Některá data bloku se týkají celkového zdraví sítě Ethereum. + +- Celkový počet transakcí - Počet transakcí od vzniku Etherea +- Transakce za sekundu - Počet transakcí zpracovatelných během jedné sekundy +- Cena ETH - Aktuální hodnota 1 ETH +- Celková nabídka ETH - Počet ETH v oběhu - nezapomeňte, že s vytvořením každého bloku vznikají nové ETH ve formě blokových odměn +- Tržní kapitalizace - Výpočítá se jako cena \* celková nabídka + +## Data konsenzuální vrstvy {#consensus-layer-data} + +### Epocha {#epoch} + +Z bezpečnostních důvodů jsou na konci každé epochy (každých 6,4 minut) vytvořeny náhodně vybrané komise validátorů. Data o epochách zahrnují: + +- Číslo epochy +- Finalizovaný stav - Zda byla epocha finalizována (ano/ne) +- Čas - Čas ukončení epochy +- Atestace - Počet atestací v epoše (hlasování pro bloky v rámci slotů) +- Vklady - Počet vložených ETH zahrnutých v epoše (validátoři musí uzamknout ETH, aby se stali validátory) +- Srážky - Počet pokut udělených navrhovatelům bloků nebo atestátorům +- Účast na hlasování - Množství uzamčených ETH použitých k atestování bloků +- Validátoři - Počet validátorů aktivních pro danou epochu +- Průměrný zůstatek validátorů - Průměrný zůstatek aktivních validátorů +- Sloty - Počet časových úseků "slotů" zahrnutých do epochy (sloty zahrnují jeden validní blok) + +### Slot {#slot} + +Sloty jsou časové úseky pro vytváření bloků, údaje dostupné pro každý slot zahrnují: + +- Epocha - Epocha, ve které je slot platný +- Číslo slotu +- Stav - Stav slotu (navržený/nepřijatý) +- Čas - Časová stopa slotu +- Navrhovatel - validátor, který navrhl blok pro slot +- Kořen bloku - Kořen stromu hashů bloku BeaconBlock +- Rodičovský kořen - Hash předcházejícího bloku +- Kořen stavu - Kořen stromového hashe bloku BeaconState +- Podpis +- Randao reveal +- Graffiti - Navrhovatel bloku může ke svému návrhu bloku připojit 32 bajtů dlouhou zprávu +- Exekuční data + - Hash bloku + - Počet vkladů + - Kořen vkladů +- Atestace - Počet atestací bloku v tomto slotu +- Vklady - Počet vkladů během tohoto slotu +- Dobrovolné odchody - Počet validátorů, kteří během tohoto slotu odešli +- Srážky - Počet pokut udělených navrhovatelům bloků nebo atestátorům +- Hlasy - Validátoři, kteří hlasovali pro blok v tomto slotu + +### Bloky {#blocks-1} + +Proof of stake dělí čas to slotů a epoch. To tedy znamená nová data! + +- Navrhovatel - validátor, který byl algoritmem vybrán, aby navrhl nový blok +- Epocha - Epocha, ve které byl blok navržen +- Slot - Časový úsek, ve kterém byl blok navržen +- Atestace - Počet atestací zahrnutých do slotu - atestace jsou jako hlasy, které označují, že blok je připraven přejít do Beacon Chainu + +### Validátoři {#validators} + +Validátoři jsou odpovědní za navrhování bloků a jejich atestaci v rámci slotů. + +- Číslo validátora - Jedinečné číslo, které reprezentuje validátora +- Aktuální zůstatek - Zůstatek validátora včetně odměn +- Efektivní zůstatek - Zůstatek validátora, který se používá pro staking (uzamčení) +- Příjem - Odměny nebo pokuty, které validátor obdržel +- Stav - Zda je validátor aktuálně online a aktivní, nebo ne +- Efektivita atestace - Průměrná doba, za kterou jsou atestace validátora zařazeny do řetězce +- Způsobilost k aktivaci - Datum (a epocha), kdy se validátor stal dostupným pro validace +- Aktivní od - Datum (a epocha), kdy se validátor stal aktivním +- Navrhované bloky - Bloky, které validátor navrhl +- Atestace - Atestace, které validátor provedl +- Vklady - Adresa odesílatele, hash transakce, číslo bloku, časové razítko, částka a stav stakovaného vkladu, který validátor provedl + +### Atestace {#attestations} + +Atestace jsou hlasy "ano" pro zařazení bloků do řetězce. Jejich data se týkají záznamu o atestaci a validátorů, kteří atestovali + +- Slot - Časový úsek, ve kterém se atestace uskutečnila +- Index komise - Index komise v daném slotu +- Agregační bity - Představuje agregovanou atestaci všech zúčastněných validátorů v atestaci +- Validátoři - Validátoři, kteří provedli atestace +- Kořen beacon bloku - Ukazuje na blok, ke kterému validátoři vydávají atestace +- Zdroj - Ukazuje na poslední oprávněnou epochu +- Cíl - Ukazuje na poslední hranici epochy +- Podpis + +### Síť {#network-1} + +Základní data o konsensuální vrstvě zahrnují následující údaje: + +- Aktuální epochu +- Aktuální slot +- Aktivní validátoty - Počet aktivních validátorů +- Čekající validátory – Počet validátorů, kteří čekají na to, až budou aktivní +- Stakované ETH - Množství ETH uzamčených v síti +- Průměrný zůstatek - Průměrný zůstatek ETH validátorů + +## Průzkumníky bloků {#block-explorers} + +- [Etherscan](https://etherscan.io/) – průzkumník bloků, který můžete použít k získávání dat pro Ethereum Mainnet a testnet. +- [3xpl](https://3xpl.com/ethereum) – open-source průzkumník Etherea bez reklam, který umožňuje stahování jeho datasetů. +- [Beaconcha.in](https://beaconcha.in/) – open-source průzkumník bloků pro Ethereum Mainnet a testnet. +- [Blockchair](https://blockchair.com/ethereum) – nejprivátnější průzkumník Etherea. Také pro třídění a filtrování dat (mempoolu) +- [Etherchain](https://www.etherchain.org/) – průzkumník bloků pro Ethereum Mainnet. +- [Ethplorer](https://ethplorer.io/) – průzkumník bloků se zaměřením na tokeny pro Ethereum Mainnet a testnet Kovan. + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Související témata {#related-topics} + +- [Transakce](/developers/docs/transactions/) +- [Účty](/developers/docs/accounts/) +- [Sítě](/developers/docs/networks/) diff --git a/public/content/translations/cs/developers/docs/data-and-analytics/index.md b/public/content/translations/cs/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..35b959ca3d2 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: Data a analytika +description: "Jak získat on-chainové analýzy a data pro použití ve vašich dapps" +lang: cs +--- + +## Úvod {#Introduction} + +S rostoucím využíváním sítě se stále větší množství cenných informací nachází v on-chain datech. Jak objem dat rychle narůstá, výpočty a agregace těchto informací za účelem reportování nebo provozu dappek se mohou stát časově i procesně náročnými. + +Využití stávajících poskytovatelů dat může urychlit vývoj, přinést přesnější výsledky a snížit náklady na údržbu. To umožní týmům vývojářů dappek soustředit se na hlavní funkce, které jejich projekt poskytuje. + +## Předpoklady {#prerequisites} + +Měli byste rozumět základnímu konceptu [průzkumníků bloků](/developers/docs/data-and-analytics/block-explorers/), abyste lépe pochopili jejich použití v kontextu analýzy dat. Kromě toho se seznamte s konceptem [indexu](/glossary/#index), abyste pochopili výhody, které přidávají k designu systému. + +Z hlediska základů architektury pochopení, co jsou [API](https://www.wikipedia.org/wiki/API) a [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), a to i jen teoreticky. + +## Průzkumníky bloků {#block-explorers} + +Mnoho [průzkumníků bloků](/developers/docs/data-and-analytics/block-explorers/) nabízí [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) brány, které vývojářům poskytnou přehled o datech v reálném čase o blocích, transakcích, validátorech, účtech a dalších on-chain aktivitách. + +Vývojáři pak mohou tato data zpracovávat a transformovat, aby svým uživatelům poskytli jedinečné vhledy a interakce s [blockchainem](/glossary/#blockchain). Například [Etherscan](https://etherscan.io) a [Blockscout](https://eth.blockscout.com) poskytují exekuční a konsensuální data pro každý 12s slot. + +## The Graph {#the-graph} + +[The Graph](https://thegraph.com/) je indexovací protokol, který poskytuje snadný způsob dotazování se na blockchainová data prostřednictvím otevřených API známých jako podgrafy. + +Díky The Graph mohou vývojáři využívat: + +- Decentralizované indexování: Umožňuje indexování blockchainových dat prostřednictvím několika indexerů, čímž se eliminuje jediný bod selhání. +- GraphQL dotazy: Poskytuje výkonné rozhraní GraphQL pro dotazování na indexovaná data, díky čemuž je získávání dat velmi jednoduché. +- Přizpůsobení: Definujte si vlastní logiku pro transformaci a ukládání blockchainových dat a znovu použijte podgrafy publikované jinými vývojáři v síti The Graph. + +Postupujte podle tohoto [rychlého průvodce](https://thegraph.com/docs/en/quick-start/) a vytvořte, nasaďte a dotazujte se na podgraf během 5 minut. + +## Diverzita klientů {#client-diversity} + +[Diverzita klientů](/developers/docs/nodes-and-clients/client-diversity/) je důležitá pro celkové zdraví sítě Ethereum, protože poskytuje odolnost vůči chybám a exploitům. Nyní existuje několik dashboardů pro diverzitu klientů, včetně [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) a [Ethernodes](https://ethernodes.org/). + +## Dune Analytics {#dune-analytics} + +[Dune Analytics](https://dune.com/) předzpracovává blockchainová data do tabulek relační databáze (DuneSQL), umožňuje uživatelům dotazovat se na blockchainová data pomocí SQL a vytvářet dashboardy na základě výsledků dotazů. On-chainová data jsou uspořádána do 4 surových tabulek: `blocks`, `transactions`, (událostí) `logs` a (volání) `traces`. Populární kontrakty a protokoly byly dekódovány a každý z nich má svou vlastní sadu událostních a volacích tabulek. Tyto tabulky jsou dále zpracovávány a organizovány do abstraktních tabulek podle typu protokolů, například dex, půjčky, stablecoiny atd. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) je decentralizovaná, hyperškálovatelná datová platforma optimalizovaná pro poskytování efektivního přístupu bez oprávnění k velkým objemům dat. V současné době poskytuje historická on-chainová data, včetně protokolů událostí, potvrzení o transakcích, stop a rozdílů stavů pro každou transakci. SQD nabízí výkonnou sadu nástrojů pro vytváření vlastních kanálů pro extrakci a zpracování dat a dosahuje rychlosti indexování až 150k bloků za sekundu. + +Chcete-li začít, navštivte [dokumentaci](https://docs.sqd.dev/) nebo si prohlédněte [příklady pro EVM](https://github.com/subsquid-labs/squid-evm-examples) toho, co můžete s SQD vytvořit. + +## Síť SubQuery {#subquery-network} + +[SubQuery](https://subquery.network/) je přední indexátor dat, který vývojářům poskytuje rychlá, spolehlivá, decentralizovaná a přizpůsobená API pro jejich web3 projekty. SubQuery umožňuje vývojářům z více než 165 ekosystémů (včetně Etherea) používat bohatě indexovaná data k vytváření intuitivních a imersivních zážitků pro jejich uživatele. Síť SubQuery pohání vaše nezastavitelné aplikace díky odolné a decentralizované infrastruktuře. Použijte vývojářskou sadu nástrojů SubQuery pro blockchain k vytváření web3 aplikací budoucnosti, aniž byste museli trávit čas budováním vlastního backendu pro zpracování dat. + +Začněte tím, že navštívíte [rychlého průvodce pro Ethereum](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) a během několika minut začnete indexovat data z blockchainu Etherea v místním prostředí Dockeru pro účely testování před nasazením na [spravovanou službu SubQuery](https://managedservice.subquery.network/) nebo do [decentralizované sítě SubQuery](https://app.subquery.network/dashboard). + +## Dotazovací jazyk EVM {#evm-query-language} + +Dotazovací jazyk EVM (EQL) je jazyk podobný SQL určený k dotazování na řetězce EVM (Ethereum Virtual Machine). Konečným cílem EQL je podporovat komplexní relační dotazy na prvky první třídy řetězce EVM (bloky, účty a transakce) a zároveň poskytovat vývojářům a výzkumníkům ergonomickou syntaxi pro každodenní použití. S EQL mohou vývojáři získávat blockchainová data pomocí známé syntaxe podobné SQL a eliminovat tak potřebu složitého šablonovitého kódu. EQL podporuje standardní požadavky na blockchainová data (např. získání nonce a zůstatku účtu na Ethereu nebo získání aktuální velikosti bloku a časového razítka) a neustále přidává podporu pro složitější požadavky a sady funkcí. + +## Další čtení {#further-reading} + +- [Zkoumání krypto dat I: Architektury datových toků](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [Přehled sítě The Graph](https://thegraph.com/docs/en/about/) +- [Hřiště pro dotazy The Graph](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [Příklady kódu API na EtherScanu](https://etherscan.io/apis#contracts) +- [Dokumentace API na Blockscoutu](https://docs.blockscout.com/devs/apis) +- [Průzkumník řetězové vazby Beaconcha.in](https://beaconcha.in) +- [Základy Dune](https://docs.dune.com/#dune-basics) +- [Rychlý průvodce pro Ethereum od SubQuery](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [Přehled sítě SQD](https://docs.sqd.dev/) +- [Dotazovací jazyk EVM](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/cs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/cs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..16f612b4b50 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "Strategie ukládání dat na blockchainu" +description: "Existuje několik způsobů, jak ukládat data pomocí blockchainu. Tento článek porovná různé strategie, jejich náklady a kompromisy, a také požadavky na jejich bezpečné používání." +lang: cs +--- + +Existuje několik způsobů, jak ukládat informace buď přímo na blockchainu, nebo způsobem, který je blockchainem zabezpečen: + +- Bloby EIP-4844 +- Calldata +- Mimo řetězec s mechanismy L1 +- Kód kontraktu +- Události +- Úložiště EVM + +Volba metody závisí na několika kritériích: + +- Zdroj informací. Informace v calldata nemohou pocházet přímo ze samotného blockchainu. +- Cíl informací. Calldata je dostupná pouze v transakci, která ji obsahuje. Události nejsou na řetězci vůbec přístupné. +- Jaká míra obtíží je přijatelná? Počítače, na kterých běží plnohodnotný uzel, mohou provádět více zpracování než lehký klient v aplikaci běžící v prohlížeči. +- Je nutné zajistit snadný přístup k informacím z každého uzlu? +- Požadavky na zabezpečení. + +## Požadavky na zabezpečení {#security-requirements} + +Obecně se bezpečnost informací skládá ze tří atributů: + +- _Důvěrnost_, neoprávněné subjekty nesmějí informace číst. To je v mnoha případech důležité, ale ne tady. _Na blockchainu neexistují žádná tajemství_. Blockchainy fungují, protože kdokoli může ověřit přechody stavů, takže je nelze použít k přímému ukládání tajemství. Existují způsoby, jak ukládat důvěrné informace na blockchain, ale všechny se spoléhají na nějakou komponentu mimo řetězec, která ukládá alespoň klíč. + +- _Integrita_, informace jsou správné, nemohou je měnit neoprávněné subjekty ani neoprávněnými způsoby (například přenos [tokenů ERC-20](https://eips.ethereum.org/EIPS/eip-20#events) bez události `Transfer`). Na blockchainu každý uzel ověřuje každou změnu stavu, což zajišťuje integritu. + +- _Dostupnost_, informace jsou dostupné jakémukoli oprávněnému subjektu. Na blockchainu se toho obvykle dosahuje tak, že jsou informace dostupné na každém [plném uzlu](https://ethereum.org/developers/docs/nodes-and-clients#full-node). + +Všechna zde uvedená řešení mají vynikající integritu, protože haše jsou zveřejňovány na L1. Mají však různé záruky dostupnosti. + +## Předpoklady {#prerequisites} + +Měli byste dobře rozumět [základům blockchainu](/developers/docs/intro-to-ethereum/). Tato stránka také předpokládá, že je čtenář obeznámen s [bloky](/developers/docs/blocks/), [transakcemi](/developers/docs/transactions/) a dalšími relevantními tématy. + +## Bloby EIP-4844 {#eip-4844-blobs} + +Počínaje [hardforkem Dencun](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) obsahuje blockchain Etherea [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), který do Etherea přidává datové bloby s omezenou životností (původně asi [18 dní](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). Cena těchto blobů se stanovuje odděleně od [exekučního paliva](/developers/docs/gas), i když se používá podobný mechanismus. Jsou levným způsobem, jak zveřejnit dočasná data. + +Hlavním případem použití blobů EIP-4844 je zveřejňování transakcí rollupy. [Optimistické rollupy](/developers/docs/scaling/optimistic-rollups) musí zveřejňovat transakce na svých blockchainech. Tyto transakce musí být dostupné komukoli během [období pro napadení](https://docs.optimism.io/connect/resources/glossary#challenge-period), aby [validátoři](https://docs.optimism.io/connect/resources/glossary#validator) mohli opravit chybu, pokud [sekvencer](https://docs.optimism.io/connect/resources/glossary#sequencer) rollupu zveřejní nesprávný kořen stavu. + +Jakmile však období pro napadení uplyne a kořen stavu je finalizován, zbývajícím účelem znalosti těchto transakcí je replikace aktuálního stavu řetězce. Tento stav je také dostupný z uzlů řetězce, přičemž je zapotřebí mnohem méně zpracování. Informace o transakcích by se tedy měly stále uchovávat na několika místech, například v [prohlížečích bloků](/developers/docs/data-and-analytics/block-explorers), ale není třeba platit za úroveň odolnosti vůči cenzuře, kterou Ethereum poskytuje. + +[Rollupy s nulovou znalostí](/developers/docs/scaling/zk-rollups/#data-availability) také zveřejňují svá transakční data, aby ostatní uzly mohly replikovat existující stav a ověřit důkazy platnosti, ale opět se jedná o krátkodobý požadavek. + +V době psaní tohoto článku stojí zveřejnění na EIP-4844 jeden wei (10-18 ETH) za bajt, což je zanedbatelné ve srovnání s [21 000 exekučního paliva, které stojí jakákoli transakce, včetně té, která zveřejňuje bloby](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Aktuální cenu EIP-4844 si můžete prohlédnout na [blobscan.com](https://blobscan.com/blocks). + +Zde jsou adresy, na kterých si můžete prohlédnout bloby zveřejněné některými známými rollupy. + +| Rollup | Adresa poštovní schránky | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +Calldata označuje bajty odeslané jako součást transakce. Jsou uložena jako součást trvalého záznamu blockchainu v bloku, který danou transakci obsahuje. + +Toto je nejlevnější metoda pro trvalé vložení dat do blockchainu. Cena za bajt je buď 4 exekučního paliva (pokud je bajt nulový) nebo 16 paliva (jakákoli jiná hodnota). Pokud jsou data komprimována, což je standardní postup, pak je každá hodnota bajtu stejně pravděpodobná, takže průměrná cena je přibližně 15,95 paliva za bajt. + +V době psaní tohoto článku jsou ceny 12 gwei/palivo a 2300 $/ETH, což znamená, že cena je přibližně 45 centů za kilobajt. Protože se jednalo o nejlevnější metodu před EIP-4844, je to metoda, kterou rollupy používaly k ukládání informací o transakcích, které musí být dostupné pro [napadení chyb](https://docs.optimism.io/stack/protocol/overview#fault-proofs), ale nemusí být přístupné přímo na řetězci. + +Zde jsou adresy, na kterých si můžete prohlédnout transakce zveřejněné některými známými rollupy. + +| Rollup | Adresa poštovní schránky | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Mimo řetězec s mechanismy L1 {#offchain-with-l1-mechs} + +V závislosti na vašich bezpečnostních kompromisech může být přijatelné umístit informace jinam a použít mechanismus, který zajistí dostupnost dat v případě potřeby. Aby to fungovalo, jsou zapotřebí dva požadavky: + +1. Zveřejněte na blockchainu [haš](https://en.wikipedia.org/wiki/Cryptographic_hash_function) dat, nazývaný _závazek vstupu_. Může to být jediné 32bajtové slovo, takže to není drahé. Dokud je k dispozici závazek vstupu, je zaručena integrita, protože není možné najít jiná data, která by se hašovala na stejnou hodnotu. Pokud jsou tedy poskytnuta nesprávná data, lze je odhalit. + +2. Mít mechanismus, který zajišťuje dostupnost. Například v [Redstone](https://redstone.xyz/docs/what-is-redstone) může jakýkoli uzel podat výzvu k dostupnosti. Pokud sekvencer neodpoví na řetězci do termínu, závazek vstupu se zruší, takže se informace považují za nikdy nezveřejněné. + +To je pro optimistický rollup přijatelné, protože se již spoléháme na to, že pro kořen stavu existuje alespoň jeden poctivý ověřovatel. Takový poctivý ověřovatel se také ujistí, že má data ke zpracování bloků, a vydá výzvu k dostupnosti, pokud informace nejsou k dispozici mimo řetězec. Tento typ optimistického rollupu se nazývá [plasma](/developers/docs/scaling/plasma/). + +## Kód kontraktu {#contract-code} + +Informace, které je třeba zapsat pouze jednou, nikdy se nepřepisují a musí být dostupné na řetězci, lze uložit jako kód kontraktu. To znamená, že vytvoříme "chytrý kontrakt" s daty a poté pomocí [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) informace přečteme. Výhodou je, že kopírování kódu je relativně levné. + +Kromě nákladů na rozšíření paměti stojí `EXTCODECOPY` 2600 paliva za první přístup ke kontraktu (když je "studený") a 100 paliva za následné kopie ze stejného kontraktu plus 3 paliva za 32bajtové slovo. Ve srovnání s calldata, které stojí 15,95 za bajt, je to levnější od přibližně 200 bajtů. Na základě [vzorce pro náklady na rozšíření paměti](https://www.evm.codes/about#memoryexpansion), pokud nepotřebujete více než 4 MB paměti, jsou náklady na rozšíření paměti menší než náklady na přidání calldata. + +Samozřejmě, to jsou jen náklady na _přečtení_ dat. Vytvoření kontraktu stojí přibližně 32 000 paliva + 200 paliva/bajt. Tato metoda je ekonomická pouze tehdy, když je třeba stejné informace číst mnohokrát v různých transakcích. + +Kód kontraktu může být nesmyslný, pokud nezačíná na `0xEF`. Kontrakty, které začínají na `0xEF`, jsou interpretovány jako [objektový formát ethereum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), který má mnohem přísnější požadavky. + +## Události {#events} + +[Události](https://docs.alchemy.com/docs/solidity-events) jsou emitovány chytrými kontrakty a čteny softwarem mimo řetězec. +Jejich výhodou je, že kód mimo řetězec může naslouchat událostem. Cena je [palivo](https://www.evm.codes/#a0?fork=cancun), 375 plus 8 paliva za bajt dat. Při 12 gwei/palivo a 2300 $/ETH to znamená jeden cent plus 22 centů za kilobajt. + +## Úložiště {#storage} + +Chytré kontrakty mají přístup k [trvalému úložišti](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Je to však velmi drahé. Zápis 32bajtového slova do dříve prázdného slotu úložiště může [stát 22 100 paliva](https://www.evm.codes/#55?fork=cancun). Při 12 gwei/palivo a 2300 $/ETH je to asi 61 centů za operaci zápisu, neboli 19,5 $ za kilobajt. + +Toto je nejdražší forma úložiště v Ethereu. + +## Shrnutí {#summary} + +Tato tabulka shrnuje různé možnosti, jejich výhody a nevýhody. + +| Typ úložiště | Zdroj dat | Záruka dostupnosti | Dostupnost na řetězci | Další omezení | +| ---------------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------- | +| Bloby EIP-4844 | Mimo řetězec | Záruka Etherea po dobu [~18 dnů](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Je dostupný pouze haš | | +| Calldata | Mimo řetězec | Záruka Etherea navždy (součást blockchainu) | Dostupné pouze při zápisu do kontraktu a v dané transakci | | +| Mimo řetězec s mechanismy L1 | Mimo řetězec | Záruka "jednoho poctivého ověřovatele" během období pro napadení | Pouze haš | Zaručeno mechanismem napadení, pouze během období pro napadení | +| Kód kontraktu | Na řetězci nebo mimo řetězec | Záruka Etherea navždy (součást blockchainu) | Ano | Zapsáno na "náhodnou" adresu, nesmí začínat `0xEF` | +| Události | Na řetězci | Záruka Etherea navždy (součást blockchainu) | Ne | | +| Úložiště | Na řetězci | Záruka Etherea navždy (součást blockchainu a současného stavu, dokud není přepsán) | Ano | | diff --git a/public/content/translations/cs/developers/docs/data-availability/index.md b/public/content/translations/cs/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..ff7b9c1ce60 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: Dostupnost dat +description: "Přehled problémů a řešení souvisejících s dostupností dat na Ethereu" +lang: cs +--- + +"Nevěř, ověř" je v ethereovské komunitě běžným rčením. Myšlenka za ním je taková, že váš síťový uzel může nezávisle ověřit, že informace, které obdrží, jsou správné, a to tak, že vykoná transakce v blocích, které přijme od ostatních uzlů, aby se ujistil, že navrhované změny přesně odpovídají těm, které tento uzel spočítal nezávisle na dalších síťových uzlech. To znamená, že uzly nemusí důvěřovat, že odesílatelé bloku jsou poctiví. To ale není možné, pokud data chybí. + +**Dostupnost dat** se týká důvěry, kterou může mít uživatel v to, že data potřebná k ověření bloku jsou skutečně dostupná všem účastníkům sítě. Pro plné uzly na 1. vrstvě Etherea je to relativně jednoduché; plný uzel si stáhne kopii všech dat v každém bloku – data _musí_ být dostupná, aby bylo stahování možné. Blok s chybějícími daty by byl zamítnut, místo toho, aby byl přidán na blockchain. Jedná se o „dostupnost on-chain dat“ a je to vlastnost monolitických blockchainů. Úplné uzly není možné oklamat přijetím neplatných transakcí, protože samy stahují a exekuují každou transakci. Pro modulární blockchainy, rollupy druhé vrstvy a jednoduché klienty je však dostupnost dat složitější a vyžaduje sofistikovanější ověřovací postupy. + +## Předpoklady {#prerequisites} + +Měli byste dobře rozumět [základům blockchainu](/developers/docs/intro-to-ethereum/) a zejména [mechanismům konsensu](/developers/docs/consensus-mechanisms/). Tato stránka také předpokládá, že čtenář je obeznámen s [bloky](/developers/docs/blocks/), [transakcemi](/developers/docs/transactions/), [uzly](/developers/docs/nodes-and-clients/), [řešeními škálovatelnosti](/developers/docs/scaling/) a dalšími relevantními tématy. + +## Problém s dostupností dat {#the-data-availability-problem} + +Problém dostupnosti dat spočívá v potřebě prokázat celé síti, že souhrnná forma nějakých transakčních dat, která jsou přidávána na blockchain, skutečně reprezentuje sadu platných transakcí, a to bez nutnosti, aby musely všechny síťové uzly stahovat všechna data. Úplná transakční data jsou nezbytná pro nezávislé ověřování bloků, ale požadavek na stažení všech transakčních dat všemi síťovými uzly je překážkou škálování. Řešení problému dostupnosti dat mají za úkol poskytnout dostatečné záruky, že všechna transakční data byla zpřístupněna pro ověření účastníkům sítě, kteří si tato data sami nestahují a neukládají. + +[Lehké uzly](/developers/docs/nodes-and-clients/light-clients) a [rollupy 2. vrstvy](/developers/docs/scaling) jsou důležitými příklady účastníků sítě, kteří vyžadují silné záruky dostupnosti dat, ale nemohou si sami stahovat a zpracovávat transakční data. Vyhýbání se stahování transakčních dat je to, co dělá jednoduché uzly jednoduchými a umožňuje rollupům být efektivním řešením pro škálování. + +Dostupnost dat je také kritickým problémem pro budoucí ["bezstavové"](/roadmap/statelessness) klienty Etherea, kteří nepotřebují stahovat a ukládat stavová data za účelem ověřování bloků. Bezstavoví klienti si stále potřebují být jisti, že data jsou _někde_ dostupná a že byla správně zpracována. + +## Řešení dostupnosti dat {#data-availability-solutions} + +### Vzorkování dostupnosti dat (DAS) {#data-availability-sampling} + +Vzorkování dostupnosti dat (DAS) je způsob, jakým může síť ověřit, že data jsou dostupná, aniž by příliš zatěžovala jakýkoliv jednotlivý síťový uzel. Každý uzel (včetně nestakujících uzlů) stahuje malou, náhodně vybranou podmnožinu všech dat. Úspěšné stažení takových vzorků potvrzuje s vysokou jistotou, že všechna data jsou dostupná. To se opírá o mazací kódování (erasure coding), které rozšiřuje danou datovou sadu o redundantní informace (dělá se to tak, že se daty proloží funkce známá jako _polynom_ a tento polynom se vyhodnotí v dalších bodech). Tento proces umožňuje obnovit původní data z redundantních dat, pokud je to nutné. Důsledkem tohoto vytvoření dat je, že pokud _jakákoli_ z původních dat nejsou dostupná, bude chybět _polovina_ rozšířených dat! Množství datových vzorků stažených každým uzlem lze vyladit tak, aby bylo _extrémně_ pravděpodobné, že alespoň jeden z datových fragmentů, které každý klient vzorkuje, bude chybět, _pokud_ je skutečně k dispozici méně než polovina dat. + +DAS se bude používat k zajištění toho, aby operátoři rollupů zpřístupnili svá transakční data po implementaci [úplného Dankshardingu](/roadmap/danksharding/#what-is-danksharding). Síťové uzly Etherea budou náhodně vzorkovat transakční data doručená v blobech pomocí výše popsaného redundantního schématu, aby ověřily, že všechna data existují. Stejnou techniku by bylo možné použít k zajištění toho, aby producenti bloků zpřístupnili všechna svá data pro zabezpečení jednoduchých klientů. Podobně v rámci [oddělení navrhovatele a stavitele bloku](/roadmap/pbs) by celý blok musel zpracovat pouze stavitel bloku – ostatní validátoři by jej ověřovali pomocí vzorkování dostupnosti dat. + +### Komise pro dostupnost dat {#data-availability-committees} + +Komise pro dostupnost dat (Data Availability Committees, DACs) jsou důvěryhodné strany, které zajišťují nebo potvrzují dostupnost dat. DAC lze použít místo DAS, [nebo v kombinaci s ním](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). Záruky bezpečnosti, které DACs poskytují, závisí na konkrétním nastavení. Ethereum například využívá k potvrzení dostupnosti dat pro jednoduché klienty náhodně vybrané podskupiny validátorů. + +DACs také využívají některá validia. V takovém případě ho tvoří důvěryhodná skupina uzlů, která uchovává kopie dat offline. DAC má povinnost tato data v případě sporu zpřístupnit. Členové DAC také publikují on-chain atestace, aby dokázali, že uvedená data jsou skutečně dostupná. Některá validia nahrazují DACs systémem validátorů založeným na proof of stake (PoS). Zde se kdokoli může stát validátorem a ukládat data offchain. Tito validátoři musí poskytnout „zástavu“, která je uložena ve smart kontraktu. V případě škodlivého chování, jako je zadržování dat, může být validátorovi tento vklad odebrán. DACs založené na proof of stake jsou výrazně bezpečnější než běžné DACs, protože jsou přímou motivací k poctivému chování. + +## Dostupnost dat a lehké uzly {#data-availability-and-light-nodes} + +[Lehké uzly](/developers/docs/nodes-and-clients/light-clients) potřebují ověřit správnost hlaviček bloků, které přijímají, aniž by stahovaly data bloku. Cena za tuto „jednoduchou" variantu je neschopnost nezávisle ověřit hlavičky bloků opětovným provedením transakcí na místní úrovni, jak to dělají úplné uzly. + +Lehké uzly Etherea důvěřují náhodným sadám 512 validátorů, které byly přiřazeny k _synchronizační komisi_. Synchronizační komise funguje jako DAC, která pomocí kryptografického podpisu signalizuje jednoduchým klientům, že data v hlavičce jsou správná. Synchronizační komise se obnovuje denně. Každá hlavička bloku upozorní lehké uzly na to, od kterých validátorů se očekává podepsání _dalšího_ bloku, takže nemohou být oklamány škodlivou skupinou, která se vydává za skutečnou synchronizační komisi. + +Co se ale stane, když se útočníkovi _podaří_ předat škodlivou hlavičku bloku lehkým klientům a přesvědčit je, že ji podepsala poctivá synchronizační komise? V takovém případě by útočník do hlavičky mohl zahrnout neplatné transakce a jednoduchý klient by je slepě přijal, protože nezávisle neověřuje všechny změny stavu zahrnuté v hlavičkách bloků. Aby se proti takovým případům efektivně bránil, může jednoduchý klient využít důkazy o podvodech (fraud proofs). + +Tyto důkazy fungují tak, že úplný uzel, který zaznamená neplatnou změnu stavu, může rychle vytvořit malý datový soubor, který prokazuje, že navrhovaná změna stavu nemohla vzniknout z dané sady transakcí, a tento důkaz rozšíří mezi své kolegy. Jednoduché uzly mohou tyto důkazy o podvodech zachytit a použít je k zamítnutí podvodných hlaviček bloků, což jim zajistí, že zůstanou na stejné - správné - větvi řetězce jako úplné uzly. + +Aby byla tato obrana funkční, musí mít úplné uzly přístup k úplným datům transakcí. Útočník, který se snaží hlavičku bloku podvrhnout a zároveň zajistí, aby byla data transakcí nedostupná, může zabránit úplným uzlům v generování důkazů o podvodu. Úplné uzly by sice mohly vydat varování před špatným blokem, ale nemohly by toto varování podložit žádným důkazem, protože data, ze kterých by bylo možné důkaz vytvořit, nebyla k dispozici! + +Řešením tohoto problému s dostupností dat je technika DAS. Jednoduché uzly stahují velmi malé náhodné části všech dat a pomocí těchto vzorků ověřují, že je k dispozici celá sada dat. Skutečnou pravděpodobnost nesprávného předpokladu plné dostupnosti dat po stažení N náhodných částí lze vypočítat ([pro 100 částí je šance 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), tj. neuvěřitelně nepravděpodobné). + +Dokonce i v tomto scénáři by si útoků, které zadržují jen několik bajtů dat, klienti, kteří by posílali náhodné požadavky na data, nemuseli všimnout. Kódování pomocí oprav chyb (erasure coding) tento problém řeší rekonstrukcí malých chybějících částí dat, které lze použít k ověření navrhovaných změn stavu. Poté by mohl být vytvořen důkaz o podvodu pomocí rekonstruovaných dat, což by zabránilo jednoduchým uzlům přijímat špatné hlavičky bloků. + +**Poznámka:** DAS a důkazy o podvodu ještě nebyly implementovány pro lehké klienty Etherea s proof-of-stake, ale jsou v plánu a s největší pravděpodobností budou mít formu důkazů založených na ZK-SNARK. Dnes se jednoduchý klient spoléhá na DAC: Ověřuje identity synchronizační komise a poté důvěřuje podepsaným hlavičkám bloků, které dostává. + +## Dostupnost dat a rollupy 2. vrstvy {#data-availability-and-layer-2-rollups} + +[Řešení škálovatelnosti 2. vrstvy](/layer-2/), jako jsou [rollupy](/glossary/#rollups), snižují transakční náklady a zvyšují propustnost Etherea zpracováváním transakcí offchain. Transakce z rollupů jsou komprimovány a následně odesílány na Ethereum v balíčcích. Dávky představují tisíce jednotlivých offchain transakcí v jedné transakci na Ethereu. To snižuje přetížení základní vrstvy, stejně jako poplatky pro uživatele. + +„Souhrnným“ transakcím zveřejněným na Ethereu je však možné důvěřovat pouze v případě, že navrhovanou změnu stavu lze nezávisle ověřit a potvrdit jako výsledek použití všech jednotlivých offchain transakcí. Pokud provozovatelé rollupů nezajistí dostupnost dat, pomocí kterých by to bylo možné ověřit, mohli by na Ethereum poslat nesprávná data. + +[Optimistické rollupy](/developers/docs/scaling/optimistic-rollups/) zveřejňují komprimovaná transakční data na Ethereu a čekají určitou dobu (obvykle 7 dní), aby nezávislí ověřovatelé mohli data zkontrolovat. Pokud někdo najde problém, může vygenerovat důkaz o podvodu a rollup s ním konfrontovat. To by způsobilo vrácení řetězce a vynechání neplatného bloku. Toto je možné pouze tehdy, pokud jsou data dostupná. V současné době existují dva způsoby, jak optimistické rollupy odesílají transakční data na L1. Některé rollupy zpřístupňují data trvale jako `CALLDATA`, která jsou trvale onchain. S implementací EIP-4844 odesílají některé rollupy svá transakční data do levnějšího úložiště v blobech. Toto úložiště není permanentní. Nezávislí ověřovatelé se musí blobů dotazovat a vznést své námitky do ~ 18 dnů: před smazáním dat z první vrstvy Etherea. Dostupnost dat je zaručena protokolem Etherea pouze na tuto krátkou pevně stanovenou dobu. Poté se odpovědnost přenáší na jiné subjekty v ekosystému Etherea. Jakýkoli uzel může ověřit dostupnost dat pomocí DAS, tj. stažením malých náhodných vzorků blob dat. + +[Rollupy s nulovou znalostí (ZK rollupy)](/developers/docs/scaling/zk-rollups) nemusí zveřejňovat transakční data, protože [důkazy platnosti s nulovou znalostí](/glossary/#zk-proof) zaručují správnost přechodů stavu. Dostupnost dat i tak představuje problém, protože nemůžeme zaručit funkčnost ZK-rollupu (nebo s ním interagovat) bez přístupu k jeho stavovým datům. Například uživatelé nemohou zjistit své zůstatky, pokud provozovatel zadrží podrobnosti o stavu rollupu. Také nemohou provádět změny stavu pomocí informací obsažených v nově přidaném bloku. + +## Dostupnost dat vs. znovu-získatelnost dat {#data-availability-vs-data-retrievability} + +Dostupnost dat se liší od opětovného získání dat. Dostupnost dat zaručuje, že úplné uzly měly přístup k úplné sadě transakcí spojené s konkrétním blokem a mohly je ověřit. To však nezaručuje, že data budou dostupná navždy. + +Znovu-získatelnost dat je schopnost uzlů získat _historické informace_ z blockchainu. Tato historická data nejsou potřebná pro ověřování nových bloků, jsou nutná pouze pro synchronizaci úplných síťových uzlů od genesis bloku nebo pro vyřízení specifických historických požadavků. + +Klíčový protokol Etherea se primárně zaměřuje na dostupnost dat, ne na jejich opětovnou dostupnost. Znovu-získatelnost dat může zajistit malá skupina archivních uzlů provozovaných třetími stranami, nebo může být distribuována po síti pomocí decentralizovaného úložiště souborů, jako je [Portal Network](https://www.ethportal.net/). + +## Další čtení {#further-reading} + +- [WTF je dostupnost dat?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Co je dostupnost dat?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [Úvod do kontrol dostupnosti dat](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [Vysvětlení návrhu tříštění + DAS](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Poznámka k dostupnosti dat a mazacímu kódování](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Komise pro dostupnost dat.](https://medium.com/starkware/data-availability-e5564c416424) +- [Komise pro dostupnost dat s proof-of-stake.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Řešení problému se znovu-získatelností dat](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [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) +- [EIP-7623: Zvýšení nákladů na Calldata](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..f5378fc1af6 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "Datové struktury a kódování" +description: "Přehled základních datových struktur Etherea." +lang: cs +sidebarDepth: 2 +--- + +Ethereum vytváří, ukládá a přenáší velké objemy dat. Tato data musí být formátována standardizovaným a paměťově efektivním způsobem, aby bylo možné [provozovat uzel](/run-a-node/) na relativně nenáročném hardwaru. K dosažení tohoto cíle se v rámci Etherea používá několik specifických datových struktur. + +## Předpoklady {#prerequisites} + +Měli byste rozumět základům Etherea a [klientskému softwaru](/developers/docs/nodes-and-clients/). Doporučuje se obeznámenost se síťovou vrstvou a [whitepaperem Etherea](/whitepaper/). + +## Datové struktury {#data-structures} + +### Patricia Merkle tries {#patricia-merkle-tries} + +Patricia Merkle Trie jsou struktury, které kódují páry klíč-hodnota do deterministického a kryptograficky ověřeného trie. Tyto struktury se hojně používají v rámci exekuční vrstvy Etherea. + +[Více o Patricia Merkle Tries](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Rekurzivní délkový prefix {#recursive-length-prefix} + +Rekurzivní délkový prefix (RLP) je metoda serializace, která se hojně využívá v rámci exekuční vrstvy Etherea. + +[Více o RLP](/developers/docs/data-structures-and-encoding/rlp) + +### Jednoduchá serializace {#simple-serialize} + +Jednoduchá serializace (SSZ) je dominantním formátem serializace v konsensuální vrstvě Etherea kvůli její kompatibilitě s merkelizací. + +[Více o SSZ](/developers/docs/data-structures-and-encoding/ssz)