`. Koncový bod Graf Explorer se používá k dotazování podgrafů v decentralizované síti Graf.
-- **Subgraph**: A custom API built on blockchain data that can be queried using [GraphQL](https://graphql.org/). Developers can build, deploy and publish subgraphs to The Graph's decentralized network. Then, Indexers can begin indexing subgraphs to make them available to be queried by subgraph consumers.
+- **Podgraf**: Otevřené API, které získává data z blockchainu, zpracovává je a ukládá tak, aby bylo možné se na ně snadno dotazovat prostřednictvím GraphQL. Vývojáři mohou vytvářet, nasazovat a publikovat podgrafy v síti Graf Poté mohou indexátoři začít indexovat podgrafy, aby je kdokoli mohl vyhledávat.
-- **Hosted service**: A temporary scaffold service for building and querying subgraphs as The Graph's decentralized network is maturing its cost of service, quality of service, and developer experience.
+- **Hostovaná služba**: Dočasná lešenářská služba pro vytváření a dotazování podgrafů v době, kdy decentralizovaná síť Graf dozrává v oblasti nákladů na služby, kvality služeb a zkušeností vývojářů.
-- **Indexers**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
+- **Indexery**: Účastníci sítě, kteří provozují indexovací uzly pro indexování dat z blockchainů a obsluhu dotazů GraphQL.
-- **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
+- **Příjmy indexátorů**: Indexátoři jsou v GRT odměňováni dvěma složkami: slevami z poplatků za dotazy a odměnami za indexování.
- 1. **Query Fee Rebates**: Payments from subgraph consumers for serving queries on the network.
+ 1. **Vrácení poplatků za dotaz**: Platby od konzumentů podgrafů za obsluhu dotazů v síti.
- 2. **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
+ 2. **Odměny za indexování**: Odměny, které indexátory obdrží za indexování podgrafů. Odměny za indexování jsou generovány prostřednictvím nové emise 3% GRT ročně.
-- **Indexer's Self Stake**: The amount of GRT that Indexers stake to participate in the decentralized network. The minimum is 100,000 GRT, and there is no upper limit.
+- **Vlastní vklad indexátora**: Částka GRT, kterou indexátoři vkládají, aby se mohli účastnit decentralizované sítě. Minimum je 100,000 GRT a horní hranice není stanovena.
-- **Upgrade Indexer**: A temporary Indexer designed to act as a fallback for subgraph queries not serviced by other Indexers on the network. It ensures a seamless transition for subgraphs upgrading from the hosted service by readily serving their queries upon being published. The upgrade Indexer is not competitive with other Indexers. It supports numerous blockchains that were previously only available on the hosted service.
+- **Upgrade indexeru**: Dočasný indexer určený jako záložní pro dotazy na podgrafy, které nejsou obsluhovány jinými indexery v síti. Zajišťuje bezproblémový přechod pro podgrafy aktualizované z hostované služby tím, že po zveřejnění snadno obslouží jejich dotazy. Upgrade Indexer není konkurenční vůči ostatním Indexerům. Podporuje řadu blokových řetězců, které byly dříve dostupné pouze v hostované službě.
-- **Delegators**: Network participants who own GRT and delegate their GRT to Indexers. This allows Indexers to increase their stake in subgraphs on the network. In return, Delegators receive a portion of the Indexing Rewards that Indexers receive for processing subgraphs.
+- **Delegátoři**: Účastníci sítě, kteří vlastní GRT a delegují své GRT na indexátory. To umožňuje Indexerům zvýšit svůj podíl v podgrafech v síti. Delegáti na oplátku dostávají část odměn za indexování, které indexátoři dostávají za zpracování podgrafů.
-- **Delegation Tax**: A 0.5% fee paid by Delegators when they delegate GRT to Indexers. The GRT used to pay the fee is burned.
+- **Delegační daň**: 0.5% poplatek, který platí delegáti, když delegují GRT na indexátory. GRT použitý k úhradě poplatku se spálí.
-- **Curators**: Network participants that identify high-quality subgraphs, and “curate” them (i.e., signal GRT on them) in exchange for curation shares. When Indexers claim query fees on a subgraph, 10% is distributed to the Curators of that subgraph. Indexers earn indexing rewards proportional to the signal on a subgraph. We see a correlation between the amount of GRT signalled and the number of Indexers indexing a subgraph.
+- **Kurátoři**: Účastníci sítě, kteří identifikují vysoce kvalitní podgrafy a "kurátorují" je (tj. signalizují na nich GRT) výměnou za kurátorské podíly. Když indexátoři požadují poplatky za dotaz na podgraf, 10% se rozdělí kurátorům tohoto podgrafu. Indexátoři získávají indexační odměny úměrné signálu na podgrafu. Vidíme korelaci mezi množstvím signalizovaných GRT a počtem indexátorů indexujících podgraf.
-- **Curation Tax**: A 1% fee paid by Curators when they signal GRT on subgraphs. The GRT used to pay the fee is burned.
+- **Curation Tax**: Kurátoři platí 1% poplatek, když signalizují GRT na podgraf GRT použitý k zaplacení poplatku se spálí.
-- **Subgraph Consumer**: Any application or user that queries a subgraph.
+- **Podgraf Spotřebitel**: Jakákoli aplikace nebo uživatel, který se dotazuje na podgraf.
-- **Subgraph Developer**: A developer who builds and deploys a subgraph to The Graph's decentralized network.
+- **Vývojář podgrafů**: Vývojář, který vytváří a nasazuje subgraf do decentralizované sítě Grafu.
-- **Subgraph Manifest**: A JSON file that describes the subgraph's GraphQL schema, data sources, and other metadata. [Here](https://ipfs.io/ipfs/QmVQdzeGdPUiLiACeqXRpKAYpyj8Z1yfWLMUq7A7WundUf) is an example.
+- **Manifest podgrafů**: Soubor JSON, který popisuje schéma podgrafu v GraphQL, zdroje dat a další metadata. [Tady](https://ipfs.io/ipfs/QmVQdzeGdPUiLiACeqXRpKAYpyj8Z1yfWLMUq7A7WundUf) je příklad.
-- **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
+- **Epoch**: Časová jednotka v rámci sítě. V současné době je jedna epocha 6,646 bloků nebo přibližně 1 den.
-- **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards subgraphs that have been published on The Graph's decentralized network. Allocations exist in one of four phases.
+- **Přidělení**: Indexer může alokovat svůj celkový podíl GRT (včetně podílu delegátů) na podgrafy, které byly zveřejněny v decentralizované síti Graf. Alokace existují v jedné ze čtyř fází.
- 1. **Active**: An allocation is considered active when it is created on-chain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular subgraph. Active allocations accrue indexing rewards proportional to the signal on the subgraph, and the amount of GRT allocated.
+ 1. **Aktivní**: Alokace je považována za aktivní, když je vytvořena v řetězci. Tomu se říká otevření alokace a signalizuje síti, že indexátor aktivně indexuje a obsluhuje dotazy pro daný podgraf. Aktivní alokace získávají odměny za indexování úměrné signálu na podgrafu a množství alokovaného GRT.
- 2. **Closed**: An Indexer may claim the accrued indexing rewards on a given subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.
+ 2. **Zavřeno**: Indexátor si může nárokovat odměny za indexaci daného podgrafu předložením aktuálního a platného dokladu o indexaci (POI). Tomuto postupu se říká uzavření přídělu. Alokace musí být otevřena minimálně jednu epochu, aby mohla být uzavřena. Maximální doba přidělení je 28 epoch. Pokud indexátor ponechá alokaci otevřenou déle než 28 epoch, je tato alokace označována jako zastaralá. Když je alokace ve stavu **uzavřeno**, může rybář stále otevřít spor a napadnout indexátor za podávání falešných dat.
- **Subgraph Studio**: A powerful dapp for building, deploying, and publishing subgraphs.
-- **Fishermen**: A role within The Graph Network held by participants who monitor the accuracy and integrity of data served by Indexers. When a Fisherman identifies a query response or a POI they believe to be incorrect, they can initiate a dispute against the Indexer. If the dispute rules in favor of the Fisherman, the Indexer is slashed. Specifically, the Indexer will lose 2.5% of their self-stake of GRT. Of this amount, 50% is awarded to the Fisherman as a bounty for their vigilance, and the remaining 50% is removed from circulation (burned). This mechanism is designed to encourage Fishermen to help maintain the reliability of the network by ensuring that Indexers are held accountable for the data they provide.
+- **Rybáři**: Úloha v rámci sítě Grafu, kterou zastávají účastníci, kteří sledují přesnost a integritu dat poskytovaných indexátory. Pokud Rybář identifikuje odpověď na dotaz nebo POI, o které se domnívá, že je nesprávná, může iniciovat spor s Indexátorem. Pokud spor rozhodne ve prospěch Rybáře, je Indexátor vyřazen. Konkrétně indexátor přijde o 2.5 % svého vlastního podílu na GRT. Z této částky je 50% přiznáno Rybáři jako odměna za jeho bdělost a zbývajících 50% je staženo z oběhu (spáleno). Tento mechanismus je navržen tak, aby Rybáře motivoval k tomu, aby pomáhali udržovat spolehlivost sítě tím, že zajistí, aby Indexátoři nesli odpovědnost za data, která poskytují.
-- **Arbitrators**: Arbitrators are network participants appointed through a governance process. The role of the Arbitrator is to decide the outcome of indexing and query disputes. Their goal is to maximize the utility and reliability of The Graph Network.
+- **Rozhodčí**: Rozhodci jsou účastníci sítě jmenovaní v rámci procesu řízení. Úkolem arbitra je rozhodovat o výsledku sporů týkajících se indexace a dotazů. Jejich cílem je maximalizovat užitečnost a spolehlivost sítě Graf.
-- **Slashing**: Indexers can have their self-staked GRT slashed for providing an incorrect POI or for serving inaccurate data. or for serving inaccurate data. The slashing percentage is a protocol parameter currently set to 2.5% of an Indexer's self stake. 50% of the slashed GRT goes to the Fisherman that disputed the inaccurate data or incorrect POI. The other 50% is burned.
+- **Slashing**: Indexerům může být sníženo jejich vlastní GRT za poskytnutí nesprávného POI nebo za poskytnutí nepřesných dat. nebo za poskytnutí nepřesných dat. Procento slashingu je parametr protokolu, který je v současné době nastaven na 2.5 % vlastního podílu indexátora. 50% z kráceného GRT připadne rybáři, který nepřesná data nebo nesprávné POI zpochybnil. Zbývajících 50% se spálí.
-- **Indexing Rewards**: The rewards that Indexers receive for indexing subgraphs. Indexing rewards are distributed in GRT.
+- **Odměny za indexování**: Odměny, které indexátory obdrží za indexování podgrafů. Odměny za indexování se rozdělují v GRT.
-- **Delegation Rewards**: The rewards that Delegators receive for delegating GRT to Indexers. Delegation rewards are distributed in GRT.
+- **Odměny za delegování**: Odměny, které delegáti obdrží za delegování GRT na indexátory. Odměny za delegování se rozdělují v GRT.
-- **GRT**: The Graph's work utility token. GRT provides economic incentives to network participants for contributing to the network.
+- **GRT**: Token pracovního nástroje Grafu. GRT poskytuje účastníkům sítě ekonomické pobídky za přispívání do sítě.
-- **POI or Proof of Indexing**: When an Indexer closes their allocation and wants to claim their accrued indexing rewards on a given subgraph, they must provide a valid and recent Proof of Indexing (POI). Fishermen may dispute the POI provided by an Indexer. A dispute resolved in the Fisherman's favor will result in slashing of the Indexer.
+- **POI nebo Doklad o indexování**: Když indexátor uzavře svůj příděl a chce si nárokovat své naběhlé odměny za indexování na daném podgrafu, musí předložit platný a aktuální doklad o indexování (POI). Rybáři mohou POI poskytnuté indexátorem zpochybnit. Spor vyřešený ve prospěch lovce bude mít za následek snížení indexátoru.
-- **Graph Node**: Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+- **Uzel grafu**: Uzel grafu je komponenta, která indexuje podgrafy a zpřístupňuje výsledná data pro dotazování prostřednictvím rozhraní GraphQL API. Jako takový je ústředním prvkem zásobníku indexátoru a správná činnost Uzel grafu je pro úspěšný provoz indexátoru klíčová.
-- **Indexer agent**: The Indexer agent is part of the indexer stack. It facilitates the Indexer's interactions on-chain, including registering on the network, managing subgraph deployments to its Graph Node(s), and managing allocations.
+- **Agent indexátoru**: Agent indexeru je součástí zásobníku indexeru. Usnadňuje interakce indexeru v řetězci, včetně registrace v síti, správy rozmístění podgrafů do jeho grafových uzlů a správy alokací.
-- **The Graph Client**: A library for building GraphQL-based dapps in a decentralized way.
+- **Klient grafu**: Knihovna pro decentralizované vytváření dapps na bázi GraphQL.
-- **Graph Explorer**: A dapp designed for network participants to explore subgraphs and interact with the protocol.
+- **Průzkumník grafů**: dapp určená pro účastníky sítě k prozkoumávání podgrafů a interakci s protokolem.
-- **Graph CLI**: A command line interface tool for building and deploying to The Graph.
+- **Graf CLI**: Nástroj rozhraní příkazového řádku pro vytváření a nasazování do Grapfu.
-- **Cooldown Period**: The time remaining until an Indexer who changed their delegation parameters can do so again.
+- **Období vychladnutí**: Doba, která zbývá do doby, než indexátor, který změnil své parametry delegování, může tuto změnu provést znovu.
-- **L2 Transfer Tools**: Smart contracts and UI that enable network participants to transfer network related assets from Ethereum mainnet to Arbitrum One. Network participants can transfer delegated GRT, subgraphs, curation shares, and Indexer's self stake.
+- **Nástroje pro přenos L2**: Chytré smlouvy a UI, které umožňují účastníkům sítě převádět aktiva související se sítí z mainnetu Ethereum do Arbitrum One. Účastníci sítě mohou převádět delegované GRT, podgrafy, kurátorské podíly a vlastní podíl Indexera.
-- **_Upgrading_ a subgraph to The Graph Network**: The process of moving a subgraph from the hosted service to The Graph Network.
+- **_Vylepšit_ podgrafu do Sítě grafů**: Proces přesunu podgrafu z hostované služby do Sítě grafů.
-- **_Updating_ a subgraph**: The process of releasing a new subgraph version with updates to the subgraph's manifest, schema, or mappings.
+- **_Aktualizace_ podgrafu**: Proces vydání nové verze podgrafu s aktualizacemi manifestu, schématu nebo mapování podgrafu.
-- **Migrating**: The process of curation shares moving from an old version of a subgraph to a new version of a subgraph (e.g. when v0.0.1 is updated to v0.0.2).
+- **Migrace**: Proces sdílení kurátorů, při kterém se přechází ze staré verze podgrafu na novou verzi podgrafu (např. při aktualizaci verze v0.0.1 na verzi v0.0.2).
diff --git a/website/pages/cs/graphcast.mdx b/website/pages/cs/graphcast.mdx
index 28a374637e81..be24a24a117f 100644
--- a/website/pages/cs/graphcast.mdx
+++ b/website/pages/cs/graphcast.mdx
@@ -2,20 +2,20 @@
title: Graphcast
---
-## Introduction
+## Úvod
-Is there something you'd like to learn from or share with your fellow Indexers in an automated manner, but it's too much hassle or costs too much gas?
+Rádi byste se něco naučili nebo se o to podělili s ostatními indexátory automatizovaným způsobem, ale je to příliš náročné nebo to stojí příliš mnoho plyn?
-Currently, the cost to broadcast information to other network participants is determined by gas fees on the Ethereum blockchain. Graphcast solves this problem by acting as an optional decentralized, distributed peer-to-peer (P2P) communication tool that allows Indexers across the network to exchange information in real time. The cost of exchanging P2P messages is near zero, with the tradeoff of no data integrity guarantees. Nevertheless, Graphcast aims to provide message validity guarantees (i.e. that the message is valid and signed by a known protocol participant) with an open design space of reputation models.
+V současné době jsou náklady na vysílání informací ostatním účastníkům sítě určovány poplatky za plyn v blockchainu Ethereum. Graphcast tento problém řeší tím, že funguje jako volitelný decentralizovaný, distribuovaný komunikační nástroj peer-to-peer (P2P), který umožňuje indexerům v celé síti vyměňovat si informace v reálném čase. Náklady na výměnu P2P zpráv jsou téměř nulové, kompromisem je absence záruk integrity dat. Nicméně Graphcast si klade za cíl poskytovat záruky platnosti zpráv (tj. že zpráva je platná a podepsaná známým účastníkem protokolu) s otevřeným prostorem pro návrh reputačních modelů.
-The Graphcast SDK (Software Development Kit) allows developers to build Radios, which are gossip-powered applications that Indexers can run to serve a given purpose. We also intend to create a few Radios (or provide support to other developers/teams that wish to build Radios) for the following use cases:
+Graphcast SDK (Vývoj softwaru Kit) umožňuje vývojářům vytvářet rádia, což jsou aplikace napájené drby, které mohou indexery spouštět k danému účelu. Máme také v úmyslu vytvořit několik Radios (nebo poskytnout podporu jiným vývojářům/týmům, které chtějí Radios vytvořit) pro následující případy použití:
-- Real-time cross-checking of subgraph data integrity ([Subgraph Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio)).
-- Conducting auctions and coordination for warp syncing subgraphs, substreams, and Firehose data from other Indexers.
-- Self-reporting on active query analytics, including subgraph request volumes, fee volumes, etc.
-- Self-reporting on indexing analytics, including subgraph indexing time, handler gas costs, indexing errors encountered, etc.
-- Self-reporting on stack information including graph-node version, Postgres version, Ethereum client version, etc.
+- Křížová kontrola integrity dat podgrafu v reálném čase ([Podgraf Radio](https://docs.graphops.xyz/graphcast/radios/subgraph-radio)).
+- Provádění aukcí a koordinace pro warp synchronizaci podgrafů, substreamů a dat Firehose z jiných Indexerů.
+- Vlastní hlášení o analýze aktivních dotazů, včetně objemů požadavků na dílčí grafy, objemů poplatků atd.
+- Vlastní hlášení o analýze indexování, včetně času indexování podgrafů, nákladů na plyn obsluhy, zjištěných chyb indexování atd.
+- Vlastní hlášení informací o zásobníku včetně verze grafového uzlu, verze Postgres, verze klienta Ethereum atd.
-### Learn More
+### Dozvědět se více
If you would like to learn more about Graphcast, [check out the documentation here.](https://docs.graphops.xyz/graphcast/intro)
diff --git a/website/pages/cs/index.json b/website/pages/cs/index.json
index ddbbb68445fe..2aadf3cd8b80 100644
--- a/website/pages/cs/index.json
+++ b/website/pages/cs/index.json
@@ -1,74 +1,74 @@
{
- "title": "Get Started",
- "intro": "Learn about The Graph, a decentralized protocol for indexing and querying data from blockchains.",
+ "title": "Začněte",
+ "intro": "Seznamte se s Grafu, decentralizovaným protokolem pro indexování a dotazování dat z blockchainů.",
"shortcuts": {
"aboutTheGraph": {
- "title": "About The Graph",
- "description": "Learn more about The Graph"
+ "title": "O grafu",
+ "description": "Další informace o Grafu"
},
"quickStart": {
- "title": "Quick Start",
- "description": "Jump in and start with The Graph"
+ "title": "Rychlé spuštění",
+ "description": "Přejděte ke Grafu a začněte s ním"
},
"developerFaqs": {
- "title": "Developer FAQs",
- "description": "Frequently asked questions"
+ "title": "FAQs vývojářů",
+ "description": "Často kladené otázky"
},
"queryFromAnApplication": {
- "title": "Query from an Application",
- "description": "Learn to query from an application"
+ "title": "Dotaz z aplikace",
+ "description": "Naučte se zadávat dotazy z aplikace"
},
"createASubgraph": {
- "title": "Create a Subgraph",
- "description": "Use Studio to create subgraphs"
+ "title": "Vytvoření podgrafu",
+ "description": "Vytváření podgrafů pomocí Studio"
},
"migrateFromHostedService": {
- "title": "Upgrade from the hosted service",
- "description": "Upgrading subgraphs to The Graph Network"
+ "title": "Upgrade z hostované služby",
+ "description": "Aktualizace podgrafů do sítě grafů"
}
},
"networkRoles": {
- "title": "Network Roles",
- "description": "Learn about The Graph’s network roles.",
+ "title": "Síťové role",
+ "description": "Zjistěte více o rolích v síti Graf.",
"roles": {
"developer": {
- "title": "Developer",
- "description": "Create a subgraph or use existing subgraphs in a dapp"
+ "title": "Vývojář",
+ "description": "Vytvoření podgrafu nebo použití existujících podgrafů v dapp"
},
"indexer": {
"title": "Indexer",
- "description": "Operate a node to index data and serve queries"
+ "description": "Provozování uzlu pro indexování dat a obsluhu dotazů"
},
"curator": {
- "title": "Curator",
- "description": "Organize data by signaling on subgraphs"
+ "title": "Kurátor",
+ "description": "Organizace dat pomocí signalizace na podgraf"
},
"delegator": {
- "title": "Delegator",
- "description": "Secure the network by delegating GRT to Indexers"
+ "title": "Delegát",
+ "description": "Zabezpečení sítě delegováním GRT na indexátory"
}
}
},
- "readMore": "Read more",
+ "readMore": "Přečtěte si více",
"products": {
- "title": "Products",
+ "title": "Produkty",
"products": {
"subgraphStudio": {
- "title": "Subgraph Studio",
- "description": "Create, manage and publish subgraphs and API keys"
+ "title": "Podgraf Studio",
+ "description": "Vytváření, správa a publikování podgrafů a klíčů API"
},
"graphExplorer": {
- "title": "Graph Explorer",
- "description": "Explore subgraphs and interact with the protocol"
+ "title": "Průzkumník grafů",
+ "description": "Prozkoumání podgrafů a interakce s protokolem"
},
"hostedService": {
- "title": "Hosted Service",
+ "title": "Hostovaná služba",
"description": "Create and explore subgraphs on the hosted service"
}
}
},
"supportedNetworks": {
- "title": "Supported Networks",
+ "title": "Podporované sítě",
"description": "The Graph supports the following networks on The Graph Network and the hosted service.",
"graphNetworkAndHostedService": "The Graph Network & hosted service",
"hostedService": "hosted service"
diff --git a/website/pages/cs/managing/deprecating-a-subgraph.mdx b/website/pages/cs/managing/deprecating-a-subgraph.mdx
index e6adfccad368..b30fe61a647a 100644
--- a/website/pages/cs/managing/deprecating-a-subgraph.mdx
+++ b/website/pages/cs/managing/deprecating-a-subgraph.mdx
@@ -1,18 +1,18 @@
---
-title: Deprecating a Subgraph
+title: Znehodnocení podgrafu
---
-So you'd like to deprecate your subgraph on The Graph Explorer. You've come to the right place! Follow the steps below:
+Rádi byste tedy svůj podgraf v Průzkumníku grafů znehodnotili. Jste na správném místě! Postupujte podle následujících kroků:
-1. Visit the contract address [here](https://etherscan.io/address/0xadca0dd4729c8ba3acf3e99f3a9f471ef37b6825#writeProxyContract)
-2. Call `deprecateSubgraph` with your `SubgraphID` as your argument.
-3. Voilà! Your subgraph will no longer show up on searches on The Graph Explorer.
+1. Navštivte adresu smlouvy [zde](https://etherscan.io/address/0xadca0dd4729c8ba3acf3e99f3a9f471ef37b6825#writeProxyContract)
+2. Volejte `deprecateSubgraph` s `SubgraphID` jako argumentem.
+3. Voilà! Váš podgraf se již nebude zobrazovat při vyhledávání v Průzkumníku grafů.
-Please note the following:
+Vezměte prosím na vědomí následující:
-- The `deprecateSubgraph` function should be called by the owner's wallet.
-- Curators will not be able to signal on the subgraph anymore.
-- Curators that already signaled on the subgraph will be able to withdraw their signal at an average share price.
+- Funkci `deprecateSubgraph` by měla volat peněženka vlastníka.
+- Kurátoři již nebudou moci signalizovat na podgrafu.
+- Kurátoři, kteří již signalizovali na subgrafu, budou moci stáhnout svůj signál za průměrnou cenu akcie.
- Deprecated subgraphs will be indicated with an error message.
If you interacted with the deprecated subgraph, you'll be able to find it in your user profile under the "Subgraphs", "Indexing", or "Curating" tab, respectively.
diff --git a/website/pages/cs/managing/transferring-subgraph-ownership.mdx b/website/pages/cs/managing/transferring-subgraph-ownership.mdx
index 1ca1c621a9c9..ba199364daae 100644
--- a/website/pages/cs/managing/transferring-subgraph-ownership.mdx
+++ b/website/pages/cs/managing/transferring-subgraph-ownership.mdx
@@ -1,32 +1,32 @@
---
-title: Transferring Subgraph Ownership
+title: Přenos vlastnictví podgrafů
---
-The Graph supports the transfer of the ownership of a subgraph.
+Graf podporuje přenos vlastnictví podgrafu.
-When you deploy a subgraph to mainnet, an NFT will be minted to the address that deployed the subgraph. The NFT is based on a standard ERC721, so it can be easily transferred to different accounts.
+Při nasazení podgrafu do mainnetu bude na adresu, ze které byl podgraf nasazen, vyražen NFT. NFT je založena na standardním ERC721, takže ji lze snadno přenášet na různé účty.
-Whoever owns the NFT controls the subgraph. If the owner decides to sell the NFT, or transfer it, they will no longer be able to make edits or updates to that subgraph on the network.
+Kdo vlastní NFT, ovládá podgraf. Pokud se vlastník rozhodne NFT prodat nebo převést, nebude již moci provádět úpravy nebo aktualizace tohoto podgrafu v síti.
-In addition to adding more flexibility to the development lifecycle, this functionality makes certain use cases more convenient, such as moving your control to a multisig or a community member creating it on behalf of a DAO.
+Kromě toho, že tato funkce zvyšuje flexibilitu životního cyklu vývoje, usnadňuje také některé případy použití, například přesunutí kontroly do multisignu nebo její vytvoření členem komunity jménem DAO.
-## Viewing your subgraph as an NFT
+## Zobrazení podgrafu jako NFT
-To view your subgraph as an NFT, you can visit an NFT marketplace like OpenSea:
+Chcete-li zobrazit svůj podgraf jako NFT, můžete navštívit tržiště NFT, například OpenSea:
```
https://opensea.io/your-wallet-address
```
-Or a wallet explorer like **Rainbow.me**:
+Nebo průzkumník peněženek, jako je **Rainbow.me**:
```
https://rainbow.me/your-wallet-addres
```
-## Transferring ownership of a subgraph
+## Převod vlastnictví podgrafu
-To transfer ownership of a subgraph, you can use the UI built into Subgraph Studio:
+Chcete-li převést vlastnictví podgrafu, můžete použít UI integrované do Studio podgraf:
diff --git a/website/pages/cs/mips-faqs.mdx b/website/pages/cs/mips-faqs.mdx
index ae460989f96e..82eaf0c0fe5d 100644
--- a/website/pages/cs/mips-faqs.mdx
+++ b/website/pages/cs/mips-faqs.mdx
@@ -2,89 +2,89 @@
title: MIPs FAQs
---
-## Introduction
+## Úvod
-> Note: the MIPs program is closed as of May 2023. Thank you to all the Indexers who participated!
+> Poznámka: program MIPs je od května 2023 uzavřen. Děkujeme všem indexátorům, kteří se programu zúčastnili!
-It's an exciting time to be participating in The Graph ecosystem! During [Graph Day 2022](https://thegraph.com/graph-day/2022/) Yaniv Tal announced the [sunsetting of the hosted service](https://thegraph.com/blog/sunsetting-hosted-service/), a moment The Graph ecosystem has been working towards for many years.
+Účast v ekosystému Grafu je vzrušující! Během [Dne Grafu 2022](https://thegraph.com/graph-day/2022/) Yaniv Tal oznámil [ukončení hostované služby](https://thegraph.com/blog/sunsetting-hosted-service/), což je okamžik, na kterém ekosystém Graf pracoval mnoho let.
-To support the sunsetting of the hosted service and the migration of all of it's activity to the decentralized network, The Graph Foundation has announced the [Migration Infrastructure Providers (MIPs) program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program).
+Nadace The Graph Foundation vyhlásila program [Migration Infrastructure Providers (MIPs)](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program), který má podpořit ukončení hostované služby a migraci všech jejích aktivit do decentralizované sítě.
-The MIPs program is an incentivization program for Indexers to support them with resources to index chains beyond Ethereum mainnet and help The Graph protocol expand the decentralized network into a multi-chain infrastructure layer.
+Program MIPs je motivační program pro indexátory, který je podporuje zdroji pro indexování řetězců mimo mainnet Ethereum a pomáhá protokolu The Graph rozšířit decentralizovanou síť na infrastrukturní vrstvu s více řetězci.
-The MIPs program has allocated 0.75% of the GRT supply (75M GRT), with 0.5% to reward Indexers who contribute to bootstrapping the network and 0.25% allocated to Network Grants for subgraph developers using multi-chain subgraphs.
+Program MIPs vyčlenil 0.75% zásoby GRT (75M GRT), přičemž 0.5% je určeno na odměnu indexátorům, kteří přispívají k zavádění sítě, a 0.25% na síťové granty pro vývojáře podgrafů využívajících víceřetězcové podgrafy.
-### Useful Resources
+### Užitečné zdroje
- [Indexer 2ools from Vincent (Victor) Taglia](https://indexer-2ools.vincenttaglia.com/#/)
-- [How to Become an Effective Indexer on The Graph Network](https://thegraph.com/blog/how-to-become-indexer/)
+- [Jak se stát efektivním indexátorem v síti Graf](https://thegraph.com/blog/how-to-become-indexer/)
- [Indexer Knowledge Hub](https://thegraph.academy/indexers/)
-- [Allocation Optimiser](https://github.com/graphprotocol/allocationopt.jl)
-- [Allocation Optimization Tooling](https://github.com/anyblockanalytics/thegraph-allocation-optimization/)
+- [Optimalizátor přidělování](https://github.com/graphprotocol/allocationopt.jl)
+- [Nástroje pro optimalizaci přidělování](https://github.com/anyblockanalytics/thegraph-allocation-optimization/)
-### 1. Is it possible to generate a valid proof of indexing (POI) even if a subgraph has failed?
+### 1. Je možné vygenerovat platný důkaz indexace (POI), i když podgraf selhal?
-Yes, it is indeed.
+Ano, je to tak.
-For context, the arbitration charter, [learn more about the charter here](https://hackmd.io/@4Ln8SAS4RX-505bIHZTeRw/BJcHzpHDu#Abstract), specifies the methodology for generating a POI for a failed subgraph.
+Pro představu, charta rozhodčího řízení [více informací o chartě naleznete zde](https://hackmd.io/@4Ln8SAS4RX-505bIHZTeRw/BJcHzpHDu#Abstract) specifikuje metodiku generování POI pro neúspěšný podgraf.
-A community member, [SunTzu](https://github.com/suntzu93), has created a script to automate this process in compliance with the arbitration charter's methodology. Check out the repo [here](https://github.com/suntzu93/get_valid_poi_subgraph).
+Člen komunity [SunTzu](https://github.com/suntzu93) vytvořil skript, který tento proces automatizuje v souladu s metodikou charty rozhodčího řízení. Podívejte se na repo [zde](https://github.com/suntzu93/get_valid_poi_subgraph).
-### 2. Which chain will the MIPs program incentivise first?
+### 2. Který řetězec bude program MIPs motivovat jako první?
-The first chain that will be supported on the decentralized network is Gnosis Chain! Formerly known as xDAI, Gnosis Chain is an EVM-based chain. Gnosis Chain was selected as the first given its user-friendliness of running nodes, Indexer readiness, alignment with The Graph and adoption within web3.
+Prvním řetězcem, který bude v decentralizované síti podporován, je Gnosis Chain! Gnosis Chain, dříve známý jako xDAI, je řetězec založený na EVM. Gnosis Chain byl vybrán jako první vzhledem k uživatelské přívětivosti běžících uzlů, připravenosti Indexeru, souladu s Graf a přijetí v rámci web3.
-### 3. How will new chains be added to the MIPs program?
+### 3. Jak budou do programu MIP přidávány nové řetězce?
-New chains will be announced throughout the MIPs program, based on Indexer readiness, demand, and community sentiment. Chains will firstly be supported on the testnet and, subsequently, a GIP will be passed to support that chain on mainnet. Indexers participating in the MIPs program will choose which chains they are interested in supporting and will earn rewards per chain, in addition to earning query fees and indexing rewards on the network for serving subgraphs. MIPs participants will be scored based on their performance, ability to serve network needs, and community support.
+Nové řetězce budou vyhlašovány v průběhu programu MIPs na základě připravenosti indexátorů, poptávky a nálady komunity. Řetězce budou nejprve podporovány v testnetu a následně bude schválen GIP, který bude daný řetězec podporovat v mainnetu. Indexátoři účastnící se programu MIPs si vyberou, které řetězce mají zájem podporovat, a budou získávat odměny za každý řetězec, kromě toho budou získávat poplatky za dotazy a odměny za indexování v síti za obsluhu podgrafů. Účastníci programu MIPs budou hodnoceni na základě svého výkonu, schopnosti sloužit potřebám sítě a podpory komunity.
-### 4. How will we know when the network is ready for a new chain?
+### 4. Jak poznáme, že je síť připravena na nový řetězec?
-The Graph Foundation will be monitoring QoS performance metrics, network performance and community channels to best assess readiness. The priority is ensuring the network meets performance needs for those multi-chain dapps to be able to migrate their subgraphs.
+Nadace Graf bude sledovat výkonnostní metriky QoS, výkonnost sítě a komunitní kanály, aby mohla co nejlépe posoudit připravenost. Prioritou je zajistit, aby síť splňovala výkonnostní potřeby těch víceřetězcových dapů, které budou moci migrovat své podgrafy.
-### 5. How are rewards divided per chain?
+### 5. Jak jsou odměny rozděleny do jednotlivých řetězců?
-Given that chains vary in their requirements for syncing nodes, and they differ in query volume and adoption, rewards per chain will be decided at the end of that chain's cycle to ensure that all feedback and learnings are captured. However, at all times Indexers will also be able to earn query fees and indexing rewards once the chain is supported on the network.
+Vzhledem k tomu, že se řetězce liší svými požadavky na sync uzly a liší se i objemem dotazů a jejich přijetím, bude o odměnách pro každý řetězec rozhodnuto na konci cyklu daného řetězce, aby se zajistilo, že budou zachyceny všechny zpětné vazby a poznatky. V každém okamžiku však budou moci indexátoři získávat také odměny za dotazy a indexaci, jakmile bude řetězec v síti podporován.
-### 6. Do we need to index all the chains in the MIPs program or can we pick just one chain and index that?
+### 6. Musíme indexovat všechny řetězce v programu MIPs, nebo můžeme vybrat jen jeden řetězec a indexovat ho?
-You are welcome to index whichever chain you'd like! The goal of the MIPs program is to equip Indexers with the tools & knowledge to index the chains they desire and support the web3 ecosystems they are interested in. However, for every chain, there are phases from testnet to mainnet. Make sure to complete all the phases for the chains you are indexing. See [The MIPs notion page](https://thegraphfoundation.notion.site/MIPs-Home-911e1187f1d94d12b247317265f81059) to learn more about the phases.
+Můžete indexovat libovolný řetězec! Cílem programu MIPs je vybavit indexátory nástroji a znalostmi, aby mohli indexovat řetězce, které si přejí, a podporovat ekosystémy web3, o které mají zájem. Pro každý řetězec však existují fáze od testnet po mainnet. Ujistěte se, že jste absolvovali všechny fáze pro řetězce, které indexujete. Více informací o fázích naleznete na stránce [The MIPs notion page](https://thegraphfoundation.notion.site/MIPs-Home-911e1187f1d94d12b247317265f81059).
-### 7. When will rewards be distributed?
+### 7. Kdy budou odměny rozděleny?
-MIPs rewards will be distributed per chain once performance metrics are met and migrated subgraphs are supported by those Indexers. Look out for info about the total rewards per chain mid-way through that chain's cycle.
+Odměny MIP budou rozděleny na řetězce, jakmile budou splněny výkonnostní metriky a migrované podgrafy budou těmito indexéry podporovány. Informace o celkových odměnách za řetězec najdete v polovině cyklu daného řetězce.
-### 8. How does scoring work?
+### jak funguje bodování?
-Indexers will compete for rewards based on scoring throughout the program on the leaderboard. Program scoring will be based on:
+Indexátoři budou soutěžit o odměny na základě bodového hodnocení v průběhu celého programu na žebříčku. Bodování programu bude založeno na:
-**Subgraph Coverage**
+**pokrytí podgraf**
-- Are you providing maximal support for subgraphs per chain?
+- Poskytujete maximální podporu podgrafů na řetězec?
-- During MIPs, large Indexers are expected to stake 50%+ of subgraphs per chain they support.
+- Během MIP se od velkých indexátorů očekává, že budou sázet více než 50% podgrafů na řetězec, který podporují.
-**Quality Of Service**
+**Kvalita služeb**
-- Is the Indexer serving the chain with good Quality of Service (latency, fresh data, uptime, etc.)?
+- Obsluhuje indexer řetězec s dobrou kvalitou služby (latence, čerstvá data, provozuschopnost atd.)?
-- Is the Indexer supporting dapp developers being reactive to their needs?
+- Podporuje Indexer vývojáře dapp a reaguje na jejich potřeby?
-Is Indexer allocating efficiently, contributing to the overall health of the network?
+Přiděluje indexer efektivně a přispívá k celkovému stavu sítě?
-**Community Support**
+**Podpora komunity**
-- Is Indexer collaborating with fellow Indexers to help them get set up for multi-chain?
+- Spolupracuje Indexer s ostatními Indexery, aby jim pomohl s nastavením pro multi-chain?
-- Is Indexer providing feedback to core devs throughout the program or sharing information with Indexers in the Forum?
+- Poskytuje Indexer v průběhu programu zpětnou vazbu hlavním vývojářům nebo sdílí informace s Indexery na fórum?
-### 9. How will the Discord role be assigned?
+### 9. Jak bude přidělena role Discord?
-Moderators will assign the roles in the next few days.
+Moderátoři přidělí role v následujících dnech.
-### 10. Is it okay to start the program on a testnet and then switch to Mainnet? Will you be able to identify my node and take it into account while distributing rewards?
+### 10. Je v pořádku spustit program v testovací síti a poté přepnout na Mainnet? Budete schopni identifikovat můj uzel a zohlednit ho při rozdělování odměn?
-Yes, it is actually expected of you to do so. Several phases are on Görli and one is on the mainnet.
+Ano, ve skutečnosti se to od vás očekává. Několik fází je na Görli a jedna je na mainnetu.
### 11. At what point do you expect participants to add a mainnet deployment?
diff --git a/website/pages/cs/network-transition-faq.mdx b/website/pages/cs/network-transition-faq.mdx
deleted file mode 100644
index d3fed8968e36..000000000000
--- a/website/pages/cs/network-transition-faq.mdx
+++ /dev/null
@@ -1,245 +0,0 @@
----
-title: Network Transition FAQ
----
-
-Developers will have plenty of time to migrate their subgraphs to the decentralized network. Exact timelines will vary from network to network based on Indexer and network readiness-the hosted service will not end support for all networks at once and will not be sunset abruptly.
-
-Each network on the hosted service, including Ethereum, will sunset gradually as it is supported on the decentralized network to achieve feature parity and a high quality of service. This will happen on a network-to-network basis with help from Indexers in the [MIPs program](https://thegraph.com/blog/mips-multi-chain-indexing-incentivized-program/), to enable full support for each network on the decentralized network.
-
-To add more clarity around continued support for each network on the hosted service, these FAQs answer common questions regarding the specifics of the network transition process. If you would like to start the subgraph migration process now, here is a [step-by-step guide](https://thegraph.com/blog/how-to-migrate-ethereum-subgraph). To skip to the migration FAQ, [click here](#migration-faqs).
-
-## Hosted Service Sunset FAQs
-
-### Will I have to migrate my subgraph before the decentralized network serves core functionalities for subgraphs?
-
-Subgraph developers can begin migrating their Ethereum mainnet subgraphs now, but will not be forced to migrate subgraphs to the network before feature core functionality exists for the decentralized network and hosted service. Migration of Gnosis network subgraphs will also begin soon, with other networks to follow once Indexers have tested the networks and are ready to index them in production.
-
-### What is the timeline and process for deprecating the hosted service?
-
-All networks will have their own timelines, depending on when they are enabled on the network and the timeline it takes to get through each phase. Core developers are working to migrate the majority of hosted service traffic to the decentralized network as soon as possible.
-
-Most importantly, you will not lose access to the hosted service before core functionality is available for your specific network/subgraph on the decentralized network.
-
-The three distinct phases of hosted service deprecation for each network are:
-
-#### Phase 1 (The Sunray): Disable new subgraph creation for blockchains that have quality parity on the network
-
-In this stage, developers will no longer be able to deploy new subgraphs to the hosted service for that network. Developers will still be able to update existing subgraphs on the hosted service.
-
-No network has yet begun Phase 1 of transitioning from the hosted service to the decentralized network.
-
-As networks enter Phase 1, please note that developers can still use the rate limited Developer Preview URL in the Subgraph Studio to develop and test their subgraphs (up to 1,000 free queries) without acquiring GRT or interacting with protocol economics.
-
-#### Phase 2 (The Sunbeam): Disable subgraph updates
-
-In this phase, updates to subgraphs must be made through Subgraph Studio and subsequently published to the decentralized network. Hosted service subgraphs for networks in this phase will still exist and will be queryable, but updates to subgraphs must be made on The Graph's decentralized network.
-
-There are no exact timelines for when any network will move to this phase, as the process is driven by exit criteria surrounding core functionality, not dates.
-
-#### Phase 3 (The Sunrise): Disable querying subgraphs
-
-At this phase, subgraphs on the hosted service for networks supported by The Graph Network will no longer process queries. The only way to query blockchain data for subgraphs on networks in this phase will be through the decentralized network. Test queries will still be available in [Subgraph Studio](https://thegraph.com/studio/) via the Development Query URL.
-
-Networks will not move to Phase 3 until successfully moving to Phase 2 and giving developers ample time to migrate to the decentralized network.
-
-
-
-> Note: This diagram reflects the per-network sunsetting process. Hosted service sunsetting times will vary and will not sunset all at once.
-
-### What happens to test networks like Goerli, Mumbai, etc?
-
-All networks and test networks are eligible for a free Deployment Query URL in the [Subgraph Studio](https://thegraph.com/studio/). This URL is rate limited and intended for test and development traffic. Production traffic will require a subgraph published to The Graph Network in order to have production grade redundancy and stability.
-
-
-
-### Does The Graph Network have the same functionalities as the hosted service?
-
-Indexers on The Graph Network run the most recent network-approved [release of Graph Node](https://github.com/graphprotocol/graph-node/releases), and can support any subgraph features supported in that release.
-
-Sometimes unreleased features which are still under development might be available first on the Developer Preview URL, which runs the latest main commit of [Graph Node](https://github.com/graphprotocol/graph-node). These features will then become available on the network with the next Graph Node release.
-
-Certain subgraph features are not eligible for indexing rewards, if they are not deterministic or verifiable on the network. Specific examples are fetching files from IPFS, and indexing networks not yet supported on The Graph Network.
-
-Subgraphs with these features can be published to the network, but they may not be picked up by Indexers. However, subgraphs with sufficient signal may still attract Indexers interested in collecting query fees, which any subgraph is eligible for.
-
-### How much does The Graph Network cost in comparison to running my own infrastructure?
-
-The Graph's decentralized network is 60-90% less expensive than running dedicated infrastructure, as shown in [these case studies](https://thegraph.com/docs/en/network/benefits/#low-volume-user-less-than-30000-queries-per-month).
-
-### Is there anything I should do with my hosted service subgraph after I migrate to the network?
-
-Hiding your hosted service subgraph is strongly recommended to avoid confusion. [This video](https://www.loom.com/share/7cffd2a7845e4fbd8c51f45c516cb7f9) walks through the process.
-
-### When will the decentralized network support my preferred network?
-
-There is no set timeline per network, they will be dictated by Indexer readiness via the [MIPs program](https://thegraph.com/migration-incentive-program/) where new networks are tested by Indexers. As new networks are supported on the network, users will receive ample notification to prepare for migration. Core devs and contributors to The Graph ecosystem are working to implement support for more networks as soon as possible.
-
-### Is Ethereum mainnet entering Phase 1 of the network transition process?
-
-While Ethereum was initially anticipated to begin transition off of the hosted service by the end of Q3 2022, this has been [postponed](https://thegraph.com/blog/transitioning-to-decentralized-graph-network) to address user feedback. Additional improvements to user experience, billing, and other fulfillments of user requests will drive Ethereum's hosted service transition timeline. Stay up to date on when Ethereum will enter The Sunray phase via the integration status tracker below and via [The Graph Twitter.](https://twitter.com/graphprotocol)
-
-### The Graph Network integration status tracker
-
-The table below illustrates where each network is in the network integration process. If your preferred network is not yet listed, integration has not yet begun, and that network is still fully supported by The Graph's hosted service.
-
-> This table will not include test networks, which remain free in [Subgraph Studio](https://thegraph.com/studio/).
-
-| Network | Announcing integration on The Graph Network | Network Integration complete | Phase 1: disable new subgraphs on hosted service | Phase 2: disable subgraph updates on hosted service | Phase 3: disable subgraphs on hosted service |
-| --- | :-: | :-: | :-: | :-: | :-: |
-| Ethereum | ✓ | ✓ | | | |
-| Gnosis (formerly xDAI) | ✓ | ✓\* | | | |
-| Polygon | ✓ | | | | |
-| Celo | ✓ | ✓\* | | | |
-| Arbitrum One | ✓ | ✓\* | | | |
-| Avalanche | ✓ | ✓\* | | | |
-| Optimism | ✓ | | | | |
-| Fantom | ✓ | | | | |
-
-\* The network is currently in beta on The Graph's decentralized network.
-
-## Query Fees, API Keys, and Billing FAQs
-
-### How are query fees priced?
-
-Query fee prices are impacted by query demand on the decentralized network. Core developers created a query pricing cost model language called [Agora](https://github.com/graphprotocol/agora). It enables Indexers to price queries efficiently. Learn more in the [Agora documentation](https://github.com/graphprotocol/agora/blob/master/docs/README.md).
-
-### How can I set a maximum query budget?
-
-Users can set a max query budget in the Subgraph Studio [API Key](https://thegraph.com/studio/apikeys/) section, under the Budget tab. [Watch this video](https://www.loom.com/share/b5fc533e48584cb694017392c80c75e0) for an overview of that process, as well as adjusting other parts of your API Key.
-
-Please note that setting your max query budget too low will exclude Indexers, potentially leading to poor quality service in the form of failed queries, slow queries, etc.
-
-As of the end of September 2022, it's best practice to stay within the $0.00035-$0.0004 range as the lowest max query budget.
-
-### How can I protect my API Key?
-
-Users are encouraged to restrict the API key by both subgraph and domain in the [Subgraph Studio](https://thegraph.com/studio/):
-
-
-
-### How do I fill up my API key to pay for query fees?
-
-You can fill up your billing balance in the Subgraph Studio [Billing Dashboard](https://thegraph.com/studio/billing/) by pressing the "Add GRT" button. There is ongoing work to improve this experience to add more seamless and recurring payments.
-
-[This video](https://www.loom.com/share/a81de6ef11d64c62872ea210c58c6af5) has an overview of that process.
-
-### How do I set alerts for low billing balances in my API key?
-
-Users should set a billing alert to their email address [here](https://thegraph.com/studio/settings/).
-
-Also, a banner will flash within a user's UI to warn when a billing balance is getting low.
-
-What are the best practices for managing my API key settings?
-
-A max query budget of $0.0004 is recommended to maintain low average query prices while maintaining high quality of service. This can be done in the budget billing tab of the [API Key section](https://thegraph.com/studio/apikeys/).
-
-## Migration FAQs
-
-### How can I migrate my subgraph to The Graph's decentralized network?
-
-
-
-### Are there Network Grants for subgraphs that migrate early to The Graph Network?
-
-Yes. To apply for a Network Grant, reach out [here](mailto:migration@thegraph.foundation).
-
-### Is there any financial/technical/marketing support through the migration process from The Graph ecosystem?
-
-There are Network Grants for projects to use to curate subgraphs (to attract Indexers) and pay for initial query fees (apply [here](https://thegraph.typeform.com/to/Zz8UAPri?typeform-source=thegraph.com)), a [direct channel](https://discord.gg/graphprotocol) to engineers to help every step of the way, and prioritized marketing campaigns to showcase your project after migration, exampled in these Twitter threads: [1](https://twitter.com/graphprotocol/status/1496891582401814537), [2](https://twitter.com/graphprotocol/status/1491926128302379008), & [3](https://twitter.com/graphprotocol/status/1491126245396201473).
-
-### How long do queries take?
-
-Queries take an average of 150-300 milliseconds on the decentralized network.
-
-### Is the billing process on The Graph Network more complex than on the hosted service?
-
-Yes, the UX for the network is not yet at quality parity with the hosted service. The billing UX, in particular, is still in very early stages and there are many moving parts that the core dev teams are working to abstract away from the process. Much of these improvements will be made public in the near future.
-
-### Can I pay for The Graph Network queries in fiat, credit card, or stablecoins?
-
-In the coming months, the number of steps that users need to take to pay for their subgraphs will be vastly reduced. While payments will still be made in GRT, efforts to implement a fiat on-ramp and automated payment systems to convert fiat and crypto into GRT to make recurring payments are already underway.
-
-### Will the network ever have the same UX as the hosted service?
-
-While there is still work to do, the aim is to offer comparable if not better quality UX on The Graph Network than currently exists on the hosted service. Short term, the aim is to offer a more streamlined and predictable billing experience that helps users focus more time building high-quality dapps.
-
-### How can I ensure that my subgraph will be picked up by Indexer on The Graph Network?
-
-It is recommended to curate with at least 10,000 GRT, which users can do in the same transaction as when they publish. Users can also ask the curation community to curate their subgraph [here](https://t.me/CurationStation).
-
-There are Network Grants for the early migrants to cover these initial costs. Feel free to apply [here](mailto:migration@thegraph.foundation).
-
-### Why does a subgraph need curation signal? What if there isn't enough signal on my subgraph from curators?
-
-The higher the curation signal, the more attractive a subgraph is to Indexers, as there is a linear correlation between higher signal and higher indexing rewards. Without curation, there is no incentive for Indexers to pick up a subgraph.
-
-### What happens to the GRT a subgraph developer uses for curation signal?
-
-If you are the first to signal a subgraph, your GRT signaled amount will not go down. GRT used for curation can be removed later. Also, Curators get 10% of all query fees taken in by Indexers.
-
-### What improvements are coming to the curation process?
-
-Short term, the initial curation model on Arbitrum will provide principle-protection to curation signal. Longer term, the core devs will prioritize offering developers the capacity to rent curation signal, opening up a more predictable pricing experience while still ensuring subgraphs are sufficiently indexed.
-
-### How do I switch the subgraph API in the front-end?
-
-After at least one Indexer has fully indexed a subgraph, a user can query the decentralized network.
-
-In order to retrieve the query URL for your subgraph, you can copy/paste it by clicking on the symbol next to the query URL. You will see something like this:
-
-`https://gateway.thegraph.com/api/[api-key]/subgraphs/id/S9ihna8D733WTEShJ1KctSTCvY1VJ7gdVwhUujq4Ejo`
-
-Simply replace [api-key] with an API key generated in the Subgraph Studio [API Key section](https://thegraph.com/studio/apikeys/).
-
-### How much do queries cost?
-
-The average query cost within the network varies. For the month of September 2022, the average price per query fee cost ranged from $0.00012 - $0.00020.
-
-### How can I find out how much volume my subgraph has and how much it will cost?
-
-Hosted service volume data is not public. Please reach out to get volume and cost estimates [here](mailto:migration@thegraph.foundation).
-
-### How does the gateway work? Is it fully decentralized?
-
-The gateway process queries so Indexers can serve dapps. The gateways are in an intermediate phase that is being progressively decentralized. More on this soon.
-
-## Using The Network FAQs
-
-### Is there a cost to update my subgraph?
-
-Yes, it is 1% of curation signaled. The 1% is split evenly between Curators (0.5%) and subgraph developers (0.5%). So, for every 10K GRT signaled, it costs subgraph developers 50 GRT to update.
-
-### How do I speed up sync time?
-
-Minimize the use of smart contract calls within the subgraph. Accessing a smart contract state requires an eth_call to the RPC, which slows down sync times.
-
-### Is there multisig support in Subgraph Studio as I migrate?
-
-Yes, multisig support has recently been added. You can find more information [here](https://thegraph.com/docs/studio/multisig).
-
-### What are the contract addresses for GRT on Ethereum and Arbitrum?
-
-- Ethereum: `0xc944E90C64B2c07662A292be6244BDf05Cda44a7`
-- Ethereum Goerli: `0x5c946740441C12510a167B447B7dE565C20b9E3C`
-- Arbitrum: `0x9623063377AD1B27544C965cCd7342f7EA7e88C7`
-- Arbitrum Goerli: `0x18c924bd5e8b83b47efadd632b7178e2fd36073d`
-
-### How much GRT do projects usually keep in their API Key?
-
-Many projects keep 30-60 days worth of GRT in their API key, so they don't need to refill often. To understand what your 30-60 day GRT fees would be, please reach out [here](mailto:migration@thegraph.foundation).
-
-### How are query payments made on the decentralized network?
-
-Fees are invoiced weekly and pulled out of a user's API Key, with GRT that is bridged to and sits on Arbitrum.
-
-### How are API keys used for subgraphs on the decentralized network?
-
-API Keys empower users to have a say in both the max query prices they pay and to prioritize factors like price, economic freshness, and query speed.
-
-### How does quality of service currently compare between the hosted service and the decentralized network?
-
-The hosted service and decentralized network have about the same median latency, but the decentralized network tends to have higher latency at higher percentiles. 200 rates for queries are generally similar, with both > 99.9%. As a result of its decentralization, the network has not had a broad outage across subgraphs, whereas the hosted service does on rare occasions have temporary outages as a result of its centralized nature.
-
-### What if my question isn't answered by these FAQs?
-
-Please reach out to [migration@thegraph.foundation](mailto:migration@thegraph.foundation) for any additional assistance.
diff --git a/website/pages/cs/network/benefits.mdx b/website/pages/cs/network/benefits.mdx
index 864672b16515..02655bef5cdb 100644
--- a/website/pages/cs/network/benefits.mdx
+++ b/website/pages/cs/network/benefits.mdx
@@ -34,7 +34,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Dec
| Engineering time† | $400 per month | None, built into the network with globally distributed Indexers |
| Queries per month | Limited to infra capabilities | 30,000 (autoscaling) |
| Cost per query | $0 | $0.0005‡ |
-| Infrastructure | Centralized | Decentralized |
+| Infrastruktura | Centralized | Decentralized |
| Geographic redundancy | $750+ per additional node | Included |
| Uptime | Varies | 99.9%+ |
| Total Monthly Costs | $750+ | ~$15 |
@@ -48,7 +48,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Dec
| Engineering time† | $800 per month | None, built into the network with globally distributed Indexers |
| Queries per month | Limited to infra capabilities | 3,000,000+ |
| Cost per query | $0 | $0.00025‡ |
-| Infrastructure | Centralized | Decentralized |
+| Infrastruktura | Centralized | Decentralized |
| Engineering expense | $200 per hour | Included |
| Geographic redundancy | $1,200 in total costs per additional node | Included |
| Uptime | Varies | 99.9%+ |
@@ -64,7 +64,7 @@ Query costs may vary; the quoted cost is the average at time of publication (Dec
| Engineering time† | $6,000 or more per month | None, built into the network with globally distributed Indexers |
| Queries per month | Limited to infra capabilities | 30,000,000+ |
| Cost per query | $0 | $0.00015‡ |
-| Infrastructure | Centralized | Decentralized |
+| Infrastruktura | Centralized | Decentralized |
| Geographic redundancy | $1,200 in total costs per additional node | Included |
| Uptime | Varies | 99.9%+ |
| Total Monthly Costs | $11,000+ | $4,500 |
diff --git a/website/pages/cs/network/curating.mdx b/website/pages/cs/network/curating.mdx
index 797d9b9dd896..c9ced1831766 100644
--- a/website/pages/cs/network/curating.mdx
+++ b/website/pages/cs/network/curating.mdx
@@ -1,93 +1,93 @@
---
-title: Curating
+title: Kurátorování
---
-Curators are critical to the Graph decentralized economy. They use their knowledge of the web3 ecosystem to assess and signal on the subgraphs that should be indexed by The Graph Network. Through the Explorer, curators are able to view network data to make signaling decisions. The Graph Network rewards curators who signal on good quality subgraphs with a share of the query fees that subgraphs generate. Curators are economically incentivized to signal early. These cues from curators are important for Indexers, who can then process or index the data from these signaled subgraphs.
+Kurátoři mají pro graf decentralizovanou ekonomiku zásadní význam. Využívají své znalosti ekosystému web3 k posuzování a signalizaci podgrafů, které by měly být indexovány sítí Graf. Prostřednictvím Průzkumníka mohou kurátoři prohlížet data sítě a rozhodovat o signalizaci. síť Graf odměňuje kurátory, kteří signalizují kvalitní podgrafy, podílem na poplatcích za dotazy, které podgrafy generují. Kurátoři jsou ekonomicky motivováni k včasné signalizaci. Tyto signály od kurátorů jsou důležité pro indexátory, kteří pak mohou zpracovávat nebo indexovat data z těchto signalizovaných podgrafů.
-When signaling, curators can decide to signal on a specific version of the subgraph or to signal using auto-migrate. When signaling using auto-migrate, a Curator’s shares will always be migrated to the latest version published by the developer. If you decide to signal on a specific version instead, shares will always stay on this specific version.
+Při signalizaci se kurátoři mohou rozhodnout, zda budou signalizovat na konkrétní verzi podgrafu, nebo zda budou signalizovat pomocí automatické migrace. Při signalizaci pomocí automatické migrace budou sdílení kurátora vždy migrována na nejnovější verzi zveřejněnou vývojářem. Pokud se místo toho rozhodnete signalizovat na konkrétní verzi, zůstanou sdílené položky vždy na této konkrétní verzi.
-Remember that curation is risky. Please do your diligence to make sure you curate on subgraphs you trust. Creating a subgraph is permissionless, so people can create subgraphs and call them any name they'd like. For more guidance on curation risks, check out [The Graph Academy's Curation Guide.](https://thegraph.academy/curators/)
+Nezapomeňte, že kurátorství je riskantní. Dbejte na to, abyste se ujistili, že kurátorství probíhá na podgraf, kterým důvěřujete. Vytváření podgrafů je bez oprávnění, takže lidé mohou vytvářet podgrafy a pojmenovávat je, jak chtějí. Další pokyny k rizikům kurátorství naleznete v [Průvodci kurátorstvím Akademie grafů.](https://thegraph.academy/curators/)
-## Bonding Curve 101
+## Křivka lepení 101
-First, we take a step back. Each subgraph has a bonding curve on which curation shares are minted when a user adds signal **into** the curve. Each subgraph’s bonding curve is unique. The bonding curves are architected so that the price to mint a curation share on a subgraph increases linearly, over the number of shares minted.
+Nejprve se vrátíme o krok zpět. Každý podgraf má vazební křivku, na které se razí kurátorské podíly, když uživatel přidá signál **do** křivky. Vazbová křivka každého podgrafu je jedinečná. Spojovací křivky jsou konstruovány tak, že cena za ražbu kurátorského podílu na podgrafu lineárně roste v závislosti na počtu ražených podílů.
-
+
-As a result, price increases linearly, meaning that it will get more expensive to purchase a share over time. Here’s an example of what we mean, see the bonding curve below:
+V důsledku toho se cena lineárně zvyšuje, což znamená, že nákup akcie bude v průběhu času dražší. Zde je příklad toho, co máme na mysli, viz níže uvedená vazební křivka:
-
+
-Consider we have two curators that mint shares for a subgraph:
+Uvažujme, že máme dva kurátory, kteří mintují podíly pro podgraf
-- Curator A is the first to signal on the subgraph. By adding 120,000 GRT into the curve, they are able to mint 2000 shares.
-- Curator B’s signal is on the subgraph at some point in time later. To receive the same amount of shares as Curator A, they would have to add 360,000 GRT into the curve.
-- Since both curators hold half the total of curation shares, they would receive an equal amount of curator royalties.
-- If any of the curators were now to burn their 2000 curation shares, they would receive 360,000 GRT.
-- The remaining curator would now receive all the curator royalties for that subgraph. If they were to burn their shares to withdraw GRT, they would receive 120,000 GRT.
-- **TLDR:** The GRT valuation of curation shares is determined by the bonding curve and can be volatile. There is potential to incur big losses. Signaling early means you put in less GRT for each share. By extension, this means you earn more curator royalties per GRT than later curators for the same subgraph.
+- Kurátor A signalizuje jako první na podgrafu. Přidáním 120,000 GRT do křivky se jim podaří vydolovat 2000 akcií.
+- Signál kurátora B se na podgrafu objeví v určitém časovém okamžiku později. Aby získal stejné množství podílů jako kurátor A, musel by do křivky přidat 360,000 GRT.
+- Vzhledem k tomu, že oba kurátoři mají polovinu všech kurátorských podílů, dostávali by stejnou částku kurátorských honorářů.
+- Pokud by nyní některý z kurátorů spálil svých 2000 kurátorských podílů, získal by 360,000 GRT.
+- Zbývající kurátor by nyní obdržel všechny kurátorské honoráře za tento podgraf. Pokud by své podíly spálili a vybrali GRT, získali by 120,000 GRT.
+- **TLDR:** Ocenění kurátorských akcií GRT je určeno vazebnou křivkou a může být volatilní. Existuje potenciál pro vznik velkých ztrát. Včasná signalizace znamená, že do každé akcie vložíte méně GRT. V důsledku to znamená, že vyděláte více kurátorských poplatků za GRT než pozdější kurátoři za stejný podgraf.
-In general, a bonding curve is a mathematical curve that defines the relationship between token supply and asset price. In the specific case of subgraph curation, **the price of each subgraph share increases with each token invested** and the **price of each share decreases with each token sold.**
+Obecně je vazební křivka matematická křivka, která definuje vztah mezi nabídkou žetonů a cenou aktiva. V konkrétním případě kurátorství podgrafu **cena každé akcie podgrafu roste s každým investovaným tokenem** a **cena každé akcie klesá s každým prodaným tokenem.**
-In the case of The Graph, [Bancor’s implementation of a bonding curve formula](https://drive.google.com/file/d/0B3HPNP-GDn7aRkVaV3dkVl9NS2M/view?resourcekey=0-mbIgrdd0B9H8dPNRaeB_TA) is leveraged.
+V případě Grafu se využívá [Bankorova implementace vzorce vazební křivky](https://drive.google.com/file/d/0B3HPNP-GDn7aRkVaV3dkVl9NS2M/view?resourcekey=0-mbIgrdd0B9H8dPNRaeB_TA).
-## How to Signal
+## Jak signalizovat
-Now that we’ve covered the basics about how the bonding curve works, this is how you will proceed to signal on a subgraph. Within the Curator tab on the Graph Explorer, curators will be able to signal and unsignal on certain subgraphs based on network stats. For a step-by-step overview of how to do this in the Explorer, [click here.](/network/explorer)
+Nyní, když jsme se seznámili se základy fungování vazební křivky, budete postupovat tak, že budete signalizovat na podgrafu. V rámci karty Kurátor v Průzkumníku grafu budou moci kurátoři signalizovat a nesignalizovat na určitých podgrafech na základě statistik sítě. Přehled postupu v Průzkumníku krok za krokem naleznete [kliknutím zde.](/network/explorer)
-A curator can choose to signal on a specific subgraph version, or they can choose to have their signal automatically migrate to the newest production build of that subgraph. Both are valid strategies and come with their own pros and cons.
+Kurátor si může zvolit, zda bude signalizovat na konkrétní verzi podgrafu, nebo zda se jeho signál automaticky přenese na nejnovější produkční sestavení daného podgrafu. Obě strategie jsou platné a mají své výhody i nevýhody.
-Signaling on a specific version is especially useful when one subgraph is used by multiple dApps. One dApp might need to regularly update the subgraph with new features. Another dApp might prefer to use an older, well-tested subgraph version. Upon initial curation, a 1% standard tax is incurred.
+Signalizace na konkrétní verzi je užitečná zejména tehdy, když jeden podgraf používá více dApps. Jedna dApp může potřebovat pravidelně aktualizovat podgraf o nové funkce. Jiná dApp může preferovat používání starší, dobře otestované verze podgrafu. Při počáteční kurátorské úpravě je účtována standardní daň ve výši 1 %.
-Having your signal automatically migrate to the newest production build can be valuable to ensure you keep accruing query fees. Every time you curate, a 1% curation tax is incurred. You will also pay a 0.5% curation tax on every migration. Subgraph developers are discouraged from frequently publishing new versions - they have to pay a 0.5% curation tax on all auto-migrated curation shares.
+Automatická migrace signálu na nejnovější produkční sestavení může být cenná, protože zajistí, že se poplatky za dotazy budou neustále zvyšovat. Při každém kurátorství se platí 1% kurátorský poplatek. Při každé migraci také zaplatíte 0,5% kurátorskou daň. Vývojáři podgrafu jsou odrazováni od častého publikování nových verzí - musí zaplatit 0.5% kurátorskou daň ze všech automaticky migrovaných kurátorských podílů.
-> **Note**: The first address to signal a particular subgraph is considered the first curator and will have to do much more gas-intensive work than the rest of the following curators because the first curator initializes the curation share tokens, initializes the bonding curve, and also transfers tokens into the Graph proxy.
+> **Poznámka**: První adresa, která signalizuje určitý podgraf, je považována za prvního kurátora a bude muset vykonat mnohem více práce s plynem než ostatní následující kurátoři, protože první kurátor inicializuje tokeny sdílení kurátorů, inicializuje vazební křivku a také přenáší tokeny do Graf proxy.
-## What does Signaling mean for The Graph Network?
+## Co znamená signalizace pro síť Graf?
-For end consumers to be able to query a subgraph, the subgraph must first be indexed. Indexing is a process where files, data, and metadata are looked at, cataloged, and then indexed so that results can be found faster. In order for a subgraph’s data to be searchable, it needs to be organized.
+Aby se koncoví uživatelé mohli dotazovat na podgraf, musí být podgraf nejprve indexován. Indexování je proces, při kterém jsou soubory, data a metadata prohlédnuty, katalogizovány a poté indexovány, aby bylo možné rychleji nalézt výsledky. Aby bylo možné v datech podgrafu vyhledávat, je třeba je uspořádat.
-And so, if Indexers had to guess which subgraphs they should index, there would be a low chance that they would earn robust query fees because they’d have no way of validating which subgraphs are good quality. Enter curation.
+Pokud by tedy indexátoři museli hádat, které podgrafy mají indexovat, byla by malá šance, že získají solidní poplatky za dotazy, protože by neměli možnost ověřit, které podgrafy jsou kvalitní. Nastupuje kurátorství.
-Curators make The Graph network efficient and signaling is the process that curators use to let Indexers know that a subgraph is good to index, where GRT is added to a bonding curve for a subgraph. Indexers can inherently trust the signal from a curator because upon signaling, curators mint a curation share for the subgraph, entitling them to a portion of future query fees that the subgraph drives. Curator signal is represented as ERC20 tokens called Graph Curation Shares (GCS). Curators that want to earn more query fees should signal their GRT to subgraphs that they predict will generate a strong flow of fees to the network. Curators cannot be slashed for bad behavior, but there is a deposit tax on Curators to disincentivize poor decision-making that could harm the integrity of the network. Curators also earn fewer query fees if they choose to curate on a low-quality Subgraph since there will be fewer queries to process or fewer Indexers to process those queries. See the diagram below!
+Kurátoři zefektivňují síť grafů a signalizace je proces, který kurátoři používají k tomu, aby dali indexátorům vědět, že podgraf je vhodné indexovat, přičemž GRT se přidává k vazební křivce podgrafu. Indexátoři mohou ze své podstaty důvěřovat signálu od kurátora, protože při signalizaci kurátoři vybírají podíl na kurátorství pro podgraf, který je opravňuje k části budoucích poplatků za dotazy, které podgraf vyvolá. Signál kurátora je reprezentován jako tokeny ERC20 nazývané Graph Curation Shares (GCS). Kurátoři, kteří chtějí získat více poplatků za dotazování, by měli signalizovat své GRT podgrafům, u nichž předpokládají, že budou generovat silný tok poplatků do sítě. Kurátoři nemohou být kráceni za špatné chování, ale existuje daň z vkladů pro kurátory, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě. Kurátoři také vydělají méně poplatků za dotazy, pokud se rozhodnou kurátorovat na nekvalitním podgrafu, protože bude méně dotazů ke zpracování nebo méně indexátorů, kteří budou tyto dotazy zpracovávat. Podívejte se na diagram níže!
-
+
-Indexers can find subgraphs to index based on curation signals they see in The Graph Explorer (screenshot below).
+Indexátoři mohou najít podgrafy k indexování na základě kurátorských signálů, které vidí v Průzkumníku grafů (obrázek níže).
-
+
-## Risks
+## Rizika
-1. The query market is inherently young at The Graph and there is risk that your %APY may be lower than you expect due to nascent market dynamics.
-2. Curation Fee - when a Curator signals GRT on a subgraph, they incur a 1% curation tax. This fee is burned and the rest is deposited into the reserve supply of the bonding curve.
-3. When curators burn their shares to withdraw GRT, the GRT valuation of the remaining shares will be reduced. Be aware that in some cases, curators may decide to burn their shares **all at once**. This situation may be common if a dApp developer stops versioning/improving and querying their subgraph or if a subgraph fails. As a result, remaining curators might only be able to withdraw a fraction of their initial GRT. For a network role with a lower risk profile, see [Delegators](/network/delegating).
-4. A subgraph can fail due to a bug. A failed subgraph does not accrue query fees. As a result, you’ll have to wait until the developer fixes the bug and deploys a new version.
- - If you are subscribed to the newest version of a subgraph, your shares will auto-migrate to that new version. This will incur a 0.5% curation tax.
- - If you have signaled on a specific subgraph version and it fails, you will have to manually burn your curation shares. Note that you may receive more or less GRT than you initially deposited into the curation curve, which is a risk associated with being a curator. You can then signal on the new subgraph version, thus incurring a 1% curation tax.
+1. Trh s dotazy je v Graf ze své podstaty mladý a existuje riziko, že vaše %APY může být nižší, než očekáváte, v důsledku dynamiky rodícího se trhu.
+2. Kurátorský poplatek - když kurátor signalizuje GRT na podgrafu, platí 1% kurátorský poplatek. Tento poplatek se spálí a zbytek se uloží do rezervní zásoby vazební křivky.
+3. Když kurátoři spálí své podíly za účelem výběru GRT, sníží se ocenění GRT zbývajících podílů. Uvědomte si, že v některých případech se kurátoři mohou rozhodnout spálit své podíly **všechny najednou**. Tato situace může být běžná, pokud vývojář dApp přestane verzovat/vylepšovat a dotazovat se na svůj podgraf nebo pokud podgraf selže. V důsledku toho mohou být zbývající kurátoři schopni vybrat pouze zlomek svého původního GRT. Síťovou roli s nižším rizikovým profilem naleznete v části [Delegátoři](/network/delegating).
+4. Podgraf může selhat kvůli chybě. Za neúspěšný podgraf se neúčtují poplatky za dotaz. V důsledku toho budete muset počkat, až vývojář chybu opraví a nasadí novou verzi.
+ - Pokud jste přihlášeni k odběru nejnovější verze podgrafu, vaše sdílené položky se automaticky přemigrují na tuto novou verzi. Při tom bude účtována 0,5% kurátorská daň.
+ - Pokud jste signalizovali na konkrétní verzi podgrafu a nepodařilo se to, budete muset ručně vypálit sdílení kurátorů. Všimněte si, že můžete obdržet více nebo méně GRT, než jste původně vložili do kurátorského podílu, což je riziko spojené s funkcí kurátora. Poté můžete signalizovat na nové verzi podgrafu, čímž vám vznikne 1% daň z kurátorství.
-## Curation FAQs
+## Nejčastější dotazy ke kurátorství
-### 1. What % of query fees do Curators earn?
+### 1. Kolik % z poplatků za dotazy kurátoři vydělávají?
-By signalling on a subgraph, you will earn a share of all the query fees that this subgraph generates. 10% of all query fees goes to the Curators pro-rata to their curation shares. This 10% is subject to governance.
+Signalizací na podgrafu získáte podíl ze všech poplatků za dotazy, které tento podgraf vygeneruje. 10 % všech poplatků za dotazy připadá kurátorům poměrně k jejich podílům na kurátorství. Těchto 10 % podléhá správě.
-### 2. How do I decide which subgraphs are high quality to signal on?
+### 2. Jak se rozhodnu, které podgrafy jsou kvalitní a na kterých je třeba signalizovat?
-Finding high-quality subgraphs is a complex task, but it can be approached in many different ways. As a Curator, you want to look for trustworthy subgraphs that are driving query volume. A trustworthy subgraph may be valuable if it is complete, accurate, and supports a dApp’s data needs. A poorly architected subgraph might need to be revised or re-published, and can also end up failing. It is critical for Curators to review a subgraph’s architecture or code in order to assess if a subgraph is valuable. As a result:
+Nalezení kvalitních podgrafů je složitý úkol, ale lze k němu přistupovat mnoha různými způsoby. Jako kurátor chcete hledat důvěryhodné podgrafy, které jsou zdrojem objemu dotazů. Důvěryhodný podgraf může být cenný, pokud je úplný, přesný a podporuje datové potřeby dApp. Špatně navržený podgraf může vyžadovat revizi nebo opětovné zveřejnění a může také skončit neúspěchem. Pro kurátory je zásadní, aby přezkoumali architekturu nebo kód podgrafu, aby mohli posoudit, zda je podgraf hodnotný. V důsledku toho:
-- Curators can use their understanding of a network to try and predict how an individual subgraph may generate a higher or lower query volume in the future
-- Curators should also understand the metrics that are available through The Graph Explorer. Metrics like past query volume and who the subgraph developer is can help determine whether or not a subgraph is worth signalling on.
+- Kurátoři mohou využít své znalosti sítě k tomu, aby se pokusili předpovědět, jak může jednotlivý podgraf v budoucnu generovat vyšší nebo nižší objem dotazů
+- Kurátoři by také měli rozumět metrikám, které jsou k dispozici prostřednictvím nástroje na graf Explorer. Metriky, jako je objem dotazů v minulosti a kdo je tvůrcem podgrafu, mohou pomoci určit, zda stojí za to podgraf signalizovat.
-### 3. What’s the cost of updating a subgraph?
+### 3. Jaké jsou náklady na aktualizaci podgrafu?
-Migrating your curation shares to a new subgraph version incurs a curation tax of 1%. Curators can choose to subscribe to the newest version of a subgraph. When curation shares get auto-migrated to a new version, Curators will also pay half curation tax, ie. 0.5%, because updating subgraphs is an on-chain action that costs gas.
+Při migraci podílů kurátorů na novou verzi podgrafů se účtuje kurátorská daň ve výši 1 %. Kurátoři se mohou rozhodnout, že si předplatí nejnovější verzi podgrafu. Při automatické migraci sdílení kurátorů na novou verzi zaplatí kurátoři také polovinu kurátorské daně, tj. 0,5 %, protože aktualizace podgrafů je akce na řetězci, která stojí plyn.
-### 4. How often can I update my subgraph?
+### 4. Jak často mohu svůj podgraf aktualizovat?
-It’s suggested that you don’t update your subgraphs too frequently. See the question above for more details.
+Doporučujeme, abyste podgrafy neaktualizovali příliš často. Další podrobnosti naleznete v otázce výše.
-### 5. Can I sell my curation shares?
+### 5. Mohu prodat své kurátorské podíly?
Curation shares cannot be "bought" or "sold" like other ERC20 tokens that you may be familiar with. They can only be minted (created) or burned (destroyed) along the bonding curve for a particular subgraph. The amount of GRT needed to mint a new signal, and the amount of GRT you receive when you burn your existing signal are determined by that bonding curve. As a Curator, you need to know that when you burn your curation shares to withdraw GRT, you can end up with more or less GRT than you initially deposited.
diff --git a/website/pages/cs/network/delegating.mdx b/website/pages/cs/network/delegating.mdx
index 4a6d6e00b73e..18b3a90c7ce0 100644
--- a/website/pages/cs/network/delegating.mdx
+++ b/website/pages/cs/network/delegating.mdx
@@ -1,98 +1,98 @@
---
-title: Delegating
+title: Delegování
---
-Delegators are network participants who delegate (i.e., "stake") GRT to one or more Indexers. Delegators contribute to securing the network without running a Graph Node themselves.
+Delegáti jsou účastníci sítě, kteří delegují (tj. "sázejí") GRT na jednoho nebo více indexátorů. Delegáti přispívají k zabezpečení sítě, aniž by sami provozovali uzel Graf.
-By delegating to an Indexer, Delegators earn a portion of the Indexer's query fees and rewards. The amount of queries an Indexer can process depends on the Indexer's own (and delegated) stake and the price the Indexer charges for each query, so the more stake that is allocated to an Indexer, the more potential queries they can process.
+Delegováním na indexátora získávají delegáti část poplatků a odměn za dotazy indexátora. Množství dotazů, které může indexátor zpracovat, závisí na jeho vlastním (a delegovaném) podílu a ceně, kterou si indexátor účtuje za každý dotaz, takže čím větší podíl je indexátorovi přidělen, tím více potenciálních dotazů může zpracovat.
-## Delegator Guide
+## Průvodce delegáta
-This guide will explain how to be an effective Delegator in the Graph Network. Delegators share earnings of the protocol alongside all Indexers based on their delegated stake. A Delegator must use their best judgment to choose Indexers based on multiple factors. Please note this guide will not go over steps such as setting up Metamask properly, as that information is widely available on the internet. There are three sections in this guide:
+V této příručce se dozvíte, jak se stát efektivním delegátem v síti Graf. Delegáti se podílejí na výnosech protokolu spolu se všemi Indexery na základě svého delegovaného podílu. Delegát musí při výběru Indexátorů vycházet ze svého nejlepšího úsudku, a to na základě více faktorů. Vezměte prosím na vědomí, že tento průvodce nebude rozebírat kroky, jako je správné nastavení Metamasky, protože tyto informace jsou široce dostupné na internetu. Tato příručka obsahuje tři části:
-- The risks of delegating tokens in The Graph Network
-- How to calculate expected returns as a Delegator
-- A video guide showing the steps to delegate in the Graph Network UI
+- Rizika delegování tokenů v síti Graf
+- Jak vypočítat očekávané výnosy jako delegát
+- Videoprůvodce ukazující kroky delegování v UI sit' Graf
-## Delegation Risks
+## Rizika delegování
-Listed below are the main risks of being a Delegator in the protocol.
+Níže jsou uvedena hlavní rizika plynoucí z delegáta v protokolu.
-### The delegation tax
+### Delegační daň
-Delegators cannot be slashed for bad behavior, but there is a tax on Delegators to disincentivize poor decision-making that could harm the integrity of the network.
+Delegáti nemohou být za špatné chování kráceni, ale existuje daň pro delegáty, která má odradit od špatného rozhodování, jež by mohlo poškodit integritu sítě.
-It is important to understand that every time you delegate, you will be charged 0.5%. This means if you are delegating 1000 GRT, you will automatically burn 5 GRT.
+Je důležité si uvědomit, že při každém delegování vám bude účtováno 0.5%. To znamená, že pokud delegujete 1000 GRT, automaticky spálíte 5 GRT.
-This means that to be safe, a Delegator should calculate what their return will be by delegating to an Indexer. For example, a Delegator might calculate how many days it will take before they have earned back the 0.5% tax on their delegation.
+To znamená, že delegát by si měl pro jistotu spočítat, jaký bude jeho výnos při delegování na indexátor. Delegát by si například mohl spočítat, za kolik dní se mu vrátí 0.5% daň z delegování.
-### The delegation unbonding period
+### Konec období vázanosti delegací
-Whenever a Delegator wants to undelegate, their tokens are subject to a 28-day unbonding period. This means they cannot transfer their tokens, or earn any rewards for 28 days.
+Kdykoli chce delegát zrušit delegování, jeho tokeny podléhají 28denní lhůtě pro zrušení delegování. To znamená, že po dobu 28 dní nemohou své tokeny převádět ani získávat žádné odměny.
-One thing to consider as well is choosing an Indexer wisely. If you choose an Indexer who was not trustworthy, or not doing a good job, you will want to undelegate, which means you will be losing a lot of opportunities to earn rewards, which can be just as bad as burning GRT.
+Jednou z věcí, kterou je třeba zvážit, je rozumný výběr indexátoru. Pokud si vyberete indexátora, který nebyl důvěryhodný nebo neodváděl dobrou práci, budete chtít zrušit delegaci, což znamená, že přijdete o mnoho příležitostí získat odměny, což může být stejně špatné jako spálení GRT.
-  _Note the 0.5% fee in the Delegation UI, as well as the 28 day
- unbonding period._
+  _Všimněte si 0.5% poplatku v UI delegací a 28denní lhůty.
+ období pro zrušení závazku._
-### Choosing a trustworthy Indexer with a fair reward payout for Delegators
+### Výběr důvěryhodného indexátora se spravedlivou odměnou pro delegáty
-This is an important part to understand. First let's discuss three very important values, which are the Delegation Parameters.
+To je důležitá část, kterou je třeba pochopit. Nejprve si probereme tři velmi důležité hodnoty, které představují parametry delegování.
-Indexing Reward Cut - The indexing reward cut is the portion of the rewards that the Indexer will keep for themselves. That means if it is set to 100%, as a Delegator you will get 0 indexing rewards. If you see 80% in the UI, that means as a Delegator, you will receive 20%. An important note - at the beginning of the network, Indexing Rewards will account for the majority of the rewards.
+Indexační podíl na odměně - Indexační podíl na odměně je část odměny, kterou si indexátor ponechá pro sebe. To znamená, že pokud je nastavena na 100%, jako delegát získáte 0 odměn za indexaci. Pokud se v uživatelském rozhraní zobrazí hodnota 80%, znamená to, že jako delegát obdržíte 20%. Důležitá poznámka - na začátku sítě budou odměny za indexování tvořit většinu odměn.
-  *The top Indexer is giving Delegators 90% of the rewards. The
- middle one is giving Delegators 20%. The bottom one is giving Delegators ~83%.*
+  *Nejlepší indexátor dává delegátům 90 % odměn. Na prostřední dává
+ delegátům 20 % odměn. Spodní dává delegátům ~83 %.*
-- Query Fee Cut - This works exactly like the Indexing Reward Cut. However, this is specifically for returns on the query fees the Indexer collects. It should be noted that at the start of the network, returns from query fees will be very small compared to the indexing reward. It is recommended to pay attention to the network to determine when the query fees in the network will start to be more significant.
+- Snížení poplatku za dotaz - Funguje stejně jako snížení odměny za indexování. Jedná se však konkrétně o výnosy z poplatků za dotaz, které indexátor vybere. Je třeba poznamenat, že na začátku sítě budou výnosy z poplatků za dotazování ve srovnání s odměnou za indexaci velmi malé. Doporučujeme věnovat pozornost síti, abyste zjistili, kdy začnou být poplatky za dotazování v síti významnější.
-As you can see, there is a lot of thought that must go into choosing the right Indexer. This is why we highly recommend you explore The Graph Discord to determine who the Indexers are with the best social reputation, and technical reputation, to reward Delegators consistently. Many of the Indexers are very active in Discord and will be happy to answer your questions. Many of them have been Indexing for months in the testnet, and are doing their best to help Delegators earn a good return, as it improves the health and success of the network.
+Jak vidíte, výběr správného indexátoru je třeba důkladně promyslet. Proto vám vřele doporučujeme prozkoumat Graf Discord a zjistit, kdo jsou Indexátoři s nejlepší společenskou reputací a technickou reputací, abyste mohli Delegáty důsledně odměňovat. Mnozí z Indexátorů jsou na Discordu velmi aktivní a rádi zodpoví vaše dotazy. Mnozí z nich indexují v testovací síti již několik měsíců a dělají vše pro to, aby pomohli Delegátům získat dobrou odměnu, protože tím zlepšují zdraví a úspěšnost sítě.
-### Calculating Delegators expected return
+### Výpočet očekávaného výnosu delegátů
-A Delegator has to consider a lot of factors when determining the return. These include:
+Delegát musí při určování návratnosti zohlednit mnoho faktorů. Mezi ně patří:
-- A technical Delegator can also look at the Indexer's ability to use the Delegated tokens available to them. If an Indexer is not allocating all the tokens available, they are not earning the maximum profit they could be for themselves or their Delegators.
-- Right now in the network an Indexer can choose to close an allocation and collect rewards anytime between 1 and 28 days. So it is possible that an Indexer has a lot of rewards they have not collected yet, and thus, their total rewards are low. This should be taken into consideration in the early days.
+- Technický delegát se může také podívat na schopnost indexátoru používat dostupné delegované tokeny. Pokud Indexátor nealokuje všechny dostupné tokeny, nevydělává pro sebe ani pro své Delegáty maximální možný zisk.
+- V současné době může indexátor v síti uzavřít alokaci a vybrat odměnu kdykoli v rozmezí 1 až 28 dnů. Je tedy možné, že indexátor má mnoho odměn, které ještě nevybral, a jeho celkové odměny jsou tedy nízké. To je třeba v prvních dnech brát v úvahu.
-### Considering the query fee cut and indexing fee cut
+### S ohledem na snížení poplatků za dotaz a indexaci
-As described in the above sections, you should choose an Indexer that is transparent and honest about setting their Query Fee Cut and Indexing Fee Cuts. A Delegator should also look at the Parameters Cooldown time to see how much of a time buffer they have. After that is done, it is fairly simple to calculate the amount of rewards the Delegators are getting. The formula is:
+Jak je popsáno v předchozích částech, měli byste si vybrat indexátor, který je transparentní a poctivý, pokud jde o nastavení snížení poplatků za dotaz a indexování. Delegovatel by se měl také podívat na dobu Cooldown parametrů, aby zjistil, jak velkou má časovou rezervu. Poté je poměrně jednoduché vypočítat výši odměn, které Delegátoři dostávají. Vzorec je následující:
-
+
-### Considering the Indexer's delegation pool
+### Zohlednění fondu delegování indexátoru
-Another thing a Delegator has to consider is what proportion of the Delegation Pool they own. All delegation rewards are shared evenly, with a simple rebalancing of the pool determined by the amount the Delegator has deposited into the pool. This gives the Delegator a share of the pool:
+Další věcí, kterou musí delegát zvážit, je, jakou část fondu delegátů vlastní. Všechny odměny za delegování se rozdělují rovnoměrně, přičemž jednoduché vyvážení fondu se určuje podle částky, kterou delegát do fondu vložil. Delegát tak získá podíl na fondu:
-
+
-Using this formula, we can see that it is actually possible for an Indexer who is offering only 20% to Delegators, to actually be giving Delegators an even better reward than an Indexer who is giving 90% to Delegators.
+Pomocí tohoto vzorce můžeme zjistit, že je možné, aby indexátor, který nabízí delegátům pouze 20%, ve skutečnosti poskytoval delegátům ještě lepší odměnu než indexátor, který poskytuje delegátům 90%.
-A Delegator can therefore do the math to determine that the Indexer offering 20% to Delegators, is offering a better return.
+Delegát tedy může výpočtem zjistit, že indexátor, který nabízí delegátům 20%, nabízí lepší výnos.
-### Considering the delegation capacity
+### Vzhledem ke kapacitě delegace
-Another thing to consider is the delegation capacity. Currently, the Delegation Ratio is set to 16. This means that if an Indexer has staked 1,000,000 GRT, their Delegation Capacity is 16,000,000 GRT of Delegated tokens that they can use in the protocol. Any delegated tokens over this amount will dilute all the Delegator rewards.
+Další věcí, kterou je třeba zvážit, je kapacita delegování. V současné době je poměr delegování nastaven na 16. To znamená, že pokud indexátor vsadil 1,000,000 GRT, jeho delegační kapacita je 16,000,000 GRT delegovaných tokenů, které může v protokolu použít. Jakékoli delegované tokeny nad toto množství rozředí všechny odměny delegátora.
-Imagine an Indexer has 100,000,000 GRT delegated to them, and their capacity is only 16,000,000 GRT. This means effectively, 84,000,000 GRT tokens are not being used to earn tokens. And all the Delegators, and the Indexer, are earning way less rewards than they could be.
+Představte si, že na indexátora je delegováno 100,000,000 BRT a jeho kapacita je pouze 16,000,000 BRT. To znamená, že efektivně 84,000,000 žetonů GRT není použito k vydělávání žetonů. A všichni delegáti i Indexer vydělávají mnohem méně odměn, než by mohli.
-Therefore a Delegator should always consider the Delegation Capacity of an Indexer, and factor it into their decision making.
+Delegát by proto měl vždy zvážit kapacitu delegování indexátora a zohlednit ji při svém rozhodování.
-## Delegator FAQs and Bugs
+## FAQ a chyby delegáta
-### MetaMask "Pending Transaction" Bug
+### Chyba MetaMask "Čekající transakce"
-**When I try to delegate my transaction in MetaMask appears as "Pending" or "Queued" for longer than expected. What should I do?**
+**Když se pokusím delegovat transakci, zobrazí se v MetaMasce jako "Pending" nebo "Queued" na delší dobu, než se očekávalo. Co mám dělat?**
-At times, attempts to delegate to indexers via MetaMask can fail and result in prolonged periods of "Pending" or "Queued" transaction attempts. For example, a user may attempt to delegate with an insufficient gas fee relative to the current prices, resulting in the transaction attempt displaying as "Pending" in their MetaMask wallet for 15+ minutes. When this occurs, subsequent transactions can be attempted by a user, but these will not be processed until the initial transaction is mined, as transactions for an address must be processed in order. In such cases, these transactions can be cancelled in MetaMask, but the transactions attempts will accrue gas fees without any guarantee that subsequent attempts will be successful. A simpler resolution to this bug is restarting the browsesr (e.g., using "abort:restart" in the address bar), which will cancel all previous attempts without gas being subtracted from the wallet. Several users that have encountered this issue and have reported successful transactions after restarting their browser and attempting to delegate.
+Občas se může stát, že pokusy o delegování na indexátory prostřednictvím funkce MetaMask selžou a vyústí v delší dobu trvající pokusy o transakci v režimu "čekající" nebo "ve frontě". Uživatel se například může pokusit o delegování s nedostatečným poplatkem za plyn vzhledem k aktuálním cenám, což vede k tomu, že se pokus o transakci v jeho peněžence MetaMask zobrazí jako "čekající" po dobu více než 15 minut. Pokud k tomu dojde, může se uživatel pokusit o další transakce, ale ty nebudou zpracovány, dokud nebude vytěžena původní transakce, protože transakce pro danou adresu musí být zpracovány v pořadí. V takových případech lze tyto transakce v MetaMasku zrušit, ale za pokusy o transakce budou narůstat poplatky za plyn bez záruky, že následné pokusy budou úspěšné. Jednodušším řešením této chyby je restartování prohlížeče (např. pomocí příkazu "abort:restart" v adresním řádku), čímž se zruší všechny předchozí pokusy, aniž by se z peněženky odečetl plyn. Několik uživatelů, kteří se s tímto problémem setkali a hlásili úspěšné transakce po restartování prohlížeče a pokusu o delegování.
-## Video guide for the network UI
+## Videoprůvodce UI sítě
-This guide provides a full review of this document, and how to consider everything in this document while interacting with the UI.
+V této příručce najdete úplný přehled tohoto dokumentu a návod, jak při práci s UI zohlednit vše, co je v tomto dokumentu uvedeno.
diff --git a/website/pages/cs/network/developing.mdx b/website/pages/cs/network/developing.mdx
index 9c543348259d..dd671220d0d6 100644
--- a/website/pages/cs/network/developing.mdx
+++ b/website/pages/cs/network/developing.mdx
@@ -1,50 +1,50 @@
---
-title: Developing
+title: Vývoj
---
-Developers are the demand side of The Graph ecosystem. Developers build subgraphs and publish them to The Graph Network. Then, they query live subgraphs with GraphQL in order to power their applications.
+Vývojáři jsou poptávkovou stranou ekosystému Grafu. Vývojáři vytvářejí podgrafy a publikují je v síti Graf. Poté se dotazují na živé podgrafy pomocí GraphQL, aby mohli využívat své aplikace.
-## Subgraph Lifecycle
+## Životní cyklus podgrafů
-Subgraphs deployed to the network have a defined lifecycle.
+Podgrafy nasazené do sítě mají definovaný životní cyklus.
-### Build locally
+### Stavět lokálně
-As with all subgraph development, it starts with local development and testing. Developers can use the same local setup whether they are building for The Graph Network, the hosted service or a local Graph Node, leveraging `graph-cli` and `graph-ts` to build their subgraph. Developers are encouraged to use tools such as [Matchstick](https://github.com/LimeChain/matchstick) for unit testing to improve the robustness of their subgraphs.
+Stejně jako při vývoji všech podgrafů se začíná lokálním vývojem a testováním. Vývojáři mohou používat stejné místní nastavení, ať už vytvářejí pro síti Graf, hostovanou službu nebo místní uzel Grafu, a využívat při vytváření podgrafu `graph-cli` a `graph-ts`. Vývojářům se doporučuje používat nástroje, jako je [Matchstick](https://github.com/LimeChain/matchstick), pro testování jednotek, aby zvýšili robustnost svých podgrafů.
-> There are certain constraints on The Graph Network, in terms of feature and network support. Only subgraphs on [supported networks](/developing/supported-networks) will earn indexing rewards, and subgraphs which fetch data from IPFS are also not eligible.
+> Síť Graf má určitá omezení, pokud jde o funkce a podporu sítě. Odměny za indexaci získají pouze podgrafy na [podporovaných sítích](/developing/supported-networks) a odměny za indexaci nemohou získat ani podgrafy, které načítají data z IPFS.
-### Deploy to the Subgraph Studio
+### Nasazení do Studio Podgraf
-Once defined, the subgraph can be built and deployed to the [Subgraph Studio](https://thegraph.com/docs/en/deploying/subgraph-studio-faqs/). The Subgraph Studio is a sandbox environment which will index the deployed subgraph and make it available for rate-limited development and testing. This gives developers an opportunity to verify that their subgraph does not encounter any indexing errors, and works as expected.
+Jakmile je podgraf definován, lze jej sestavit a nasadit do [Studio podgrafů](https://thegraph.com/docs/en/deploying/subgraph-studio-faqs/). podgraf Studio je prostředí sandboxu, které indexuje nasazený subgraf a zpřístupní jej pro vývoj a testování s omezenou rychlostí. Vývojáři tak mají možnost ověřit, zda se jejich podgraf nesetkává s žádnými chybami indexování a zda funguje podle očekávání.
-### Publish to the Network
+### Publikovat v síti
-When the developer is happy with their subgraph, they can publish it to The Graph Network. This is an on-chain action, which registers the subgraph so that it is discoverable by Indexers. Published subgraphs have a corresponding NFT, which is then easily transferable. The published subgraph has associated metadata, which provides other network participants with useful context and information.
+Jakmile je vývojář se svým podgrafem spokojen, může jej zveřejnit v síti Grafu. Jedná se o akci v řetězci, která zaregistruje podgraf tak, aby jej indexery mohly objevit. Zveřejněné podgrafy mají odpovídající NFT, který je pak snadno přenositelný. Zveřejněný podgraf má přiřazená metadata, která poskytují ostatním účastníkům sítě užitečný kontext a informace.
-### Signal to Encourage Indexing
+### Signál na podporu indexování
-Published subgraphs are unlikely to be picked up by Indexers without the addition of signal. Signal is locked GRT associated with a given subgraph, which indicates to Indexers that a given subgraph will receive query volume, and also contributes to the indexing rewards available for processing it. Subgraph developers will generally add signal to their subgraph, in order to encourage indexing. Third party Curators may also signal on a given subgraph, if they deem the subgraph likely to drive query volume.
+Publikované podgrafy pravděpodobně nebudou zachyceny indexátory bez přidání signálu. Signál je uzamčený GRT spojený s daným podgrafem, který indikuje indexátorům, že daný podgraf obdrží objem dotazů, a také přispívá k indexačním odměnám, které jsou k dispozici pro jeho zpracování. Vývojáři podgrafů obvykle přidávají ke svým podgrafům signál, aby podpořili indexování. Kurátoři třetích stran mohou také signalizovat daný podgraf, pokud se domnívají, že podgraf bude pravděpodobně vytvářet objem dotazů.
-### Querying & Application Development
+### Dotazování & Vývoj aplikací
-Once a subgraph has been processed by Indexers and is available for querying, developers can start to use the subgraph in their applications. Developers query subgraphs via a gateway, which forwards their queries to an Indexer who has processed the subgraph, paying query fees in GRT.
+Jakmile je podgraf zpracován indexery a je k dispozici pro dotazování, mohou jej vývojáři začít používat ve svých aplikacích. Vývojáři se dotazují na podgrafy prostřednictvím brány, která jejich dotazy předává indexeru, jenž podgraf zpracoval, a platí poplatky za dotazy v GRT.
-In order to make queries, developers must generate an API key, which can be done in the Subgraph Studio. This API key must be funded with GRT, in order to pay query fees. Developers can set a maximum query fee, in order to control their costs, and limit their API key to a given subgraph or origin domain. The Subgraph Studio provides developers with data on their API key usage over time.
+Aby mohli vývojáři provádět dotazy, musí si vygenerovat klíč API, což lze provést v aplikaci podgraf Studio. Tento klíč API musí být financován pomocí GRT, aby bylo možné platit poplatky za dotazy. Vývojáři mohou nastavit maximální poplatek za dotaz, aby měli pod kontrolou své náklady, a omezit svůj klíč API na daný podgraf nebo doménu původu. Subgraph Studio poskytuje vývojářům údaje o využití jejich klíče API v průběhu času.
-Developers are also able to express an Indexer preference to the gateway, for example preferring Indexers whose query response is faster, or whose data is most up to date. These controls are set in the Subgraph Studio.
+Vývojáři mohou bráně také vyjádřit preferenci indexátoru, například preferovat indexátory, jejichž odezva na dotaz je rychlejší nebo jejichž data jsou nejaktuálnější. Tyto ovládací prvky se nastavují ve studiu Podgraf Studio.
### Updating Subgraphs
-After a time a subgraph developer may want to update their subgraph, perhaps fixing a bug or adding new functionality. The subgraph developer may deploy new version(s) of their subgraph to the Subgraph Studio for rate-limited development and testing.
+Po nějaké době může chtít vývojář podgrafu svůj podgraf aktualizovat, třeba opravit chybu nebo přidat novou funkci. Vývojář subgrafu může nasadit novou verzi/verze svého podgrafu do studio Podgraf Studio pro vývoj a testování s omezenou rychlostí.
-Once the Subgraph Developer is ready to update, they can initiate a transaction to point their subgraph at the new version. Updating the subgraph migrates any signal to the new version (assuming the user who applied the signal selected "auto-migrate"), which also incurs a migration tax. This signal migration should prompt Indexers to start indexing the new version of the subgraph, so it should soon become available for querying.
+Jakmile je vývojář podgrafu připraven k aktualizaci, může iniciovat transakci, která jeho podgraf nasměruje na novou verzi. Aktualizace podgrafu migruje jakýkoli signál na novou verzi (za předpokladu, že uživatel, který signál aplikoval, zvolil "automatickou migraci"), čímž také vzniká migrační daň. Tato migrace signálu by měla přimět indexátory, aby začaly indexovat novou verzi podgrafu, takže by měl být brzy k dispozici pro dotazování.
-### Deprecating Subgraphs
+### Vyřazování podgrafů
-At some point a developer may decide that they no longer need a published subgraph. At that point they may deprecate the subgraph, which returns any signalled GRT to the Curators.
+V určitém okamžiku se vývojář může rozhodnout, že publikovaný podgraf již nepotřebuje. V tu chvíli může podgraf vyřadit, čímž se kurátorům vrátí všechny signalizované GRT.
-### Diverse Developer Roles
+### Různorodé role vývojáře
Some developers will engage with the full subgraph lifecycle on the network, publishing, querying and iterating on their own subgraphs. Some may be focused on subgraph development, building open APIs which others can build on. Some may be application focused, querying subgraphs deployed by others.
diff --git a/website/pages/cs/network/explorer.mdx b/website/pages/cs/network/explorer.mdx
index b3a549900b83..92a6940cfe8c 100644
--- a/website/pages/cs/network/explorer.mdx
+++ b/website/pages/cs/network/explorer.mdx
@@ -1,193 +1,193 @@
---
-title: Graph Explorer
+title: Průzkumník grafů
---
-Welcome to the Graph Explorer, or as we like to call it, your decentralized portal into the world of subgraphs and network data. 👩🏽🚀 The Graph Explorer consists of multiple parts where you can interact with other subgraph developers, dapp developers, Curators, Indexers, and Delegators. For a general overview of the Graph Explorer, check out the video below (or keep reading below):
+Vítejte v Průzkumníku grafů, nebo jak mu rádi říkáme, ve vašem decentralizovaném portálu do světa podgrafů a síťových dat. 👩🏽🚀 Průzkumník grafů se skládá z několika částí, ve kterých můžete komunikovat s ostatními vývojáři subgrafů, vývojáři dapp, kurátory, indexátory a delegátory. Pro obecný přehled o průzkumník grafů se podívejte na video níže (nebo pokračujte ve čtení níže):
-## Subgraphs
+## Podgrafy
-First things first, if you just finished deploying and publishing your subgraph in the Subgraph Studio, the Subgraphs tab on the top of the navigation bar is the place to view your own finished subgraphs (and the subgraphs of others) on the decentralized network. Here, you’ll be able to find the exact subgraph you’re looking for based on the date created, signal amount, or name.
+Nejdříve, pokud jste právě dokončili nasazení a publikování podgrafu ve Studio podgrafu, je karta podgrafy v horní části navigačního panelu místem pro zobrazení vlastních dokončených podgrafů (a podgrafů ostatních) v decentralizované síti. Zde budete moci najít přesně ten podgraf, který hledáte, na základě data vytvoření, množství signálu nebo názvu.
-
+
-When you click into a subgraph, you’ll be able to test queries in the playground and be able to leverage network details to make informed decisions. You’ll also be able to signal GRT on your own subgraph or the subgraphs of others to make indexers aware of its importance and quality. This is critical because signaling on a subgraph incentivizes it to be indexed, which means that it’ll surface on the network to eventually serve queries.
+Po kliknutí do podgrafu budete moci testovat dotazy na hřišti a využívat podrobnosti o síti k přijímání informovaných rozhodnutí. Budete také moci signalizovat GRT na svém vlastním podgrafu nebo podgrafech ostatních, aby si indexátory uvědomily jeho důležitost a kvalitu. To je velmi důležité, protože signalizace na podgrafu motivuje k jeho indexaci, což znamená, že se v síti objeví a nakonec bude sloužit dotazům.
-
+
-On each subgraph’s dedicated page, several details are surfaced. These include:
+Na stránce věnované každému podgrafu se objeví několik podrobností. Patří mezi ně:
-- Signal/Un-signal on subgraphs
-- View more details such as charts, current deployment ID, and other metadata
-- Switch versions to explore past iterations of the subgraph
-- Query subgraphs via GraphQL
-- Test subgraphs in the playground
-- View the Indexers that are indexing on a certain subgraph
-- Subgraph stats (allocations, Curators, etc)
-- View the entity who published the subgraph
+- Signál/nesignál na podgraf
+- Zobrazit další podrobnosti, například grafy, ID aktuálního nasazení a další metadata
+- Přepínání verzí pro zkoumání minulých iterací podgrafu
+- Dotazování na podgrafy prostřednictvím GraphQL
+- Testování podgrafů na hřišti
+- Zobrazení indexátorů, které indexují na určitém podgrafu
+- Statistiky podgrafů (alokace, kurátoři atd.)
+- Zobrazení subjektu, který podgraf zveřejnil
-
+
-## Participants
+## Účastníci
-Within this tab, you’ll get a bird’s eye view of all the people that are participating in the network activities, such as Indexers, Delegators, and Curators. Below, we’ll go into an in-depth review of what each tab means for you.
+Na této kartě získáte přehled o všech osobách, které se podílejí na činnostech sítě, jako jsou indexátoři, delegáti a kurátoři. Níže si podrobně rozebereme, co pro vás jednotlivé karty znamenají.
-### 1. Indexers
+### 1. Indexery
-
+
-Let’s start with the Indexers. Indexers are the backbone of the protocol, being the ones that stake on subgraphs, index them, and serve queries to anyone consuming subgraphs. In the Indexers table, you’ll be able to see an Indexers’ delegation parameters, their stake, how much they have staked to each subgraph, and how much revenue they have made off of query fees and indexing rewards. Deep dives below:
+Začněme u indexátorů. Základem protokolu jsou indexery, které sázejí na podgrafy, indexují je a obsluhují dotazy všech, kdo podgrafy spotřebovávají. V tabulce Indexers uvidíte parametry delegace indexerů, jejich podíl, kolik vsadili na jednotlivé podgrafy a kolik vydělali na poplatcích za dotazy a odměnách za indexování. Hlubší ponory níže:
-- Query Fee Cut - the % of the query fee rebates that the Indexer keeps when splitting with Delegators
-- Effective Reward Cut - the indexing reward cut applied to the delegation pool. If it’s negative, it means that the Indexer is giving away part of their rewards. If it’s positive, it means that the Indexer is keeping some of their rewards
-- Cooldown Remaining - the time remaining until the Indexer can change the above delegation parameters. Cooldown periods are set up by Indexers when they update their delegation parameters
-- Owned - This is the Indexer’s deposited stake, which may be slashed for malicious or incorrect behavior
-- Delegated - Stake from Delegators which can be allocated by the Indexer, but cannot be slashed
-- Allocated - Stake that Indexers are actively allocating towards the subgraphs they are indexing
-- Available Delegation Capacity - the amount of delegated stake the Indexers can still receive before they become over-delegated
-- Max Delegation Capacity - the maximum amount of delegated stake the Indexer can productively accept. An excess delegated stake cannot be used for allocations or rewards calculations.
-- Query Fees - this is the total fees that end users have paid for queries from an Indexer over all time
-- Indexer Rewards - this is the total indexer rewards earned by the Indexer and their Delegators over all time. Indexer rewards are paid through GRT issuance.
+- Query Fee Cut - % slevy z poplatku za dotaz, které si indexátor ponechá při rozdělení s delegáty
+- Efektivní snížení odměny - indexační snížení odměny použité na fond delegací. Pokud je záporná, znamená to, že indexátor odevzdává část svých odměn. Pokud je kladná, znamená to, že si indexátor ponechává část svých odměn
+- Cooldown Remaining - doba, která zbývá do doby, kdy indexátor může změnit výše uvedené parametry delegování. Období Cooldown nastavují indexátory při aktualizaci parametrů delegování.
+- Owned - Jedná se o uložený podíl indexátora, který může být zkrácen za škodlivé nebo nesprávné chování.
+- Delegated - Podíl z delegátů, který může být přidělen indexátor, ale nemůže být zkrácen
+- Allocated - Podíl, který indexátory aktivně alokují k indexovaným podgrafy
+- Dostupná kapacita delegování - množství delegovaných podílů, které mohou indexátoři ještě obdržet, než dojde k jejich nadměrnému delegování
+- Maximální kapacita delegování - maximální množství delegovaných podílů, které může indexátor produktivně přijmout. Nadměrný delegovaný podíl nelze použít pro alokace nebo výpočty odměn.
+- Poplatky za dotazy - jedná se o celkové poplatky, které koncoví uživatelé zaplatili za dotazy z indexátoru za celou dobu
+- Odměny indexátorů - jedná se o celkové odměny indexátorů, které indexátor a jeho delegáti získali za celou dobu. Odměny indexátorů jsou vypláceny prostřednictvím vydání GRT.
-Indexers can earn both query fees and indexing rewards. Functionally, this happens when network participants delegate GRT to an Indexer. This enables Indexers to receive query fees and rewards depending on their Indexer parameters. Indexing parameters are set by clicking on the right-hand side of the table, or by going into an Indexer’s profile and clicking the “Delegate” button.
+Indexátoři mohou získat jak poplatky za dotazy, tak odměny za indexování. Funkčně k tomu dochází, když účastníci sítě delegují GRT na indexátor. To indexátorům umožňuje získávat poplatky za dotazování a odměny v závislosti na parametrech indexátoru. Parametry indexování se nastavují kliknutím na pravou stranu tabulky nebo vstupem do profilu indexátora a kliknutím na tlačítko "Delegate".
-To learn more about how to become an Indexer, you can take a look at the [official documentation](/network/indexing) or [The Graph Academy Indexer guides.](https://thegraph.academy/delegators/choosing-indexers/)
+Chcete-li se dozvědět více o tom, jak se stát indexátorem, můžete se podívat do [oficiální dokumentace](/network/indexing) nebo do [průvodců pro indexátory akademie graf.](https://thegraph.academy/delegators/choosing-indexers/)
-
+
-### 2. Curators
+### 2. Kurátoři
-Curators analyze subgraphs to identify which subgraphs are of the highest quality. Once a Curator has found a potentially attractive subgraph, they can curate it by signaling on its bonding curve. In doing so, Curators let Indexers know which subgraphs are high quality and should be indexed.
+Kurátoři analyzují podgrafy, aby určili, které podgrafy jsou nejkvalitnější. Jakmile kurátor najde potenciálně atraktivní podgraf, může jej kurátorovi signalizovat na jeho vazební křivce. Kurátoři tak dávají indexátorům vědět, které podgrafy jsou vysoce kvalitní a měly by být indexovány.
-Curators can be community members, data consumers, or even subgraph developers who signal on their own subgraphs by depositing GRT tokens into a bonding curve. By depositing GRT, Curators mint curation shares of a subgraph. As a result, Curators are eligible to earn a portion of the query fees that the subgraph they have signaled on generates. The bonding curve incentivizes Curators to curate the highest quality data sources. The Curator table in this section will allow you to see:
+Kurátory mohou být členové komunity, konzumenti dat nebo dokonce vývojáři podgrafů, kteří signalizují své vlastní podgrafy tím, že vkládají žetony GRT do vazební křivky. Vložením GRT kurátoři razí kurátorské podíly podgrafu. V důsledku toho mají kurátoři nárok vydělat část poplatků za dotazy, které signalizovaný podgraf generuje. Vázací křivka motivuje kurátory ke kurátorství datových zdrojů nejvyšší kvality. Tabulka kurátorů v této části vám umožní vidět:
-- The date the Curator started curating
-- The number of GRT that was deposited
-- The number of shares a Curator owns
+- Datum, kdy kurátor zahájil kurátorskou činnost
+- Počet uložených GRT
+- Počet akcií, které kurátor vlastní
-
+
-If you want to learn more about the Curator role, you can do so by visiting the following links of [The Graph Academy](https://thegraph.academy/curators/) or [official documentation.](/network/curating)
+Pokud se chcete o roli kurátora dozvědět více, můžete tak učinit na následujících odkazech [The Graph Academy](https://thegraph.academy/curators/) nebo [oficiální dokumentace.](/network/curating)
-### 3. Delegators
+### 3. Delegáti
-Delegators play a key role in maintaining the security and decentralization of The Graph Network. They participate in the network by delegating (i.e., “staking”) GRT tokens to one or multiple indexers. Without Delegators, Indexers are less likely to earn significant rewards and fees. Therefore, Indexers seek to attract Delegators by offering them a portion of the indexing rewards and query fees that they earn.
+Delegáti hrají klíčovou roli při udržování bezpečnosti a decentralizace sítě Graf. Podílejí se na síti tím, že delegují (tj. "sází") tokeny GRT jednomu nebo více indexátorům. Bez delegátů mají indexátoři menší šanci získat významné odměny a poplatky. Proto se indexátoři snaží přilákat delegáty tím, že jim nabízejí část odměn za indexování a poplatků za dotazy, které získají.
-Delegators, in turn, select Indexers based on a number of different variables, such as past performance, indexing reward rates, and query fee cuts. Reputation within the community can also play a factor in this! It’s recommended to connect with the indexers selected via [The Graph’s Discord](https://discord.gg/graphprotocol) or [The Graph Forum](https://forum.thegraph.com/)!
+Delegáti zase vybírají indexátory na základě řady různých proměnných, jako je výkonnost v minulosti, míra odměny za indexaci a snížení poplatků za dotaz. Svou roli může hrát i pověst v rámci komunity! Doporučujeme se s vybranými indexátory spojit prostřednictvím [Discord Grafu](https://discord.gg/graphprotocol) nebo [Fóra Grafu](https://forum.thegraph.com/)!
-
+
-The Delegators table will allow you to see the active Delegators in the community, as well as metrics such as:
+Tabulka Delegáti vám umožní zobrazit aktivní delegáty v komunitě a také metriky, jako jsou:
-- The number of Indexers a Delegator is delegating towards
-- A Delegator’s original delegation
-- The rewards they have accumulated but have not withdrawn from the protocol
-- The realized rewards they withdrew from the protocol
-- Total amount of GRT they have currently in the protocol
-- The date they last delegated at
+- Počet indexátorů, na které deleguje delegát
+- Původní delegace delegát
+- Odměny, které nashromáždili, ale z protokolu si je nevyzvedli
+- Realizované odměny odstranili z protokolu
+- Celkové množství GRT, které mají v současné době v protokolu
+- Datum, kdy byly naposledy delegovány na
-If you want to learn more about how to become a Delegator, look no further! All you have to do is to head over to the [official documentation](/network/delegating) or [The Graph Academy](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
+Pokud se chcete dozvědět více o tom, jak se stát delegátem, už nemusíte hledat dál! Stačí, když se vydáte na [oficiální dokumentaci](/network/delegating) nebo [Akademii Graf](https://docs.thegraph.academy/official-docs/delegator/choosing-indexers).
-## Network
+## Síť
-In the Network section, you will see global KPIs as well as the ability to switch to a per-epoch basis and analyze network metrics in more detail. These details will give you a sense of how the network is performing over time.
+V sekci Síť uvidíte globální klíčové ukazatele výkonnosti (KPI) a také možnost přepnout na základ epoch a detailněji analyzovat síťové metriky. Tyto podrobnosti vám poskytnou představu o tom, jak síť funguje v průběhu času.
-### Activity
+### Aktivita
-The activity section has all the current network metrics as well as some cumulative metrics over time. Here you can see things like:
+V části o činnosti jsou uvedeny všechny aktuální síťové metriky a některé kumulativní metriky za určitý časový úsek. Zde můžete vidět např:
-- The current total network stake
-- The stake split between the Indexers and their Delegators
-- Total supply, minted, and burned GRT since the network inception
-- Total Indexing rewards since the inception of the protocol
-- Protocol parameters such as curation reward, inflation rate, and more
-- Current epoch rewards and fees
+- Současný celkový podíl v síti
+- Rozdělení stake mezi indexátory a jejich delegátory
+- Celková nabídka, vytěžené a spálené GRT od založení sítě
+- Celkové odměny za indexaci od zavedení protokolu
+- Parametry protokolu, jako je odměna za kurátorství, míra inflace a další
+- Odměny a poplatky současné epochy
-A few key details that are worth mentioning:
+Několik klíčových informací, které stojí za zmínku:
-- **Query fees represent the fees generated by the consumers**, and they can be claimed (or not) by the Indexers after a period of at least 7 epochs (see below) after their allocations towards the subgraphs have been closed and the data they served has been validated by the consumers.
-- **Indexing rewards represent the amount of rewards the Indexers claimed from the network issuance during the epoch.** Although the protocol issuance is fixed, the rewards only get minted once the Indexers close their allocations towards the subgraphs they’ve been indexing. Thus the per-epoch number of rewards varies (ie. during some epochs, Indexers might’ve collectively closed allocations that have been open for many days).
+- **Poplatky za dotazy představují poplatky generované spotřebiteli** a indexátory si je mohou nárokovat (nebo ne) po uplynutí nejméně 7 epoch (viz níže) poté, co byly jejich příděly vůči podgraf uzavřeny a data, která obsluhovali, byla potvrzena spotřebiteli.
+- ** Odměny za indexaci představují množství odměn, které indexátoři nárokovali ze síťové emise během epochy.** Ačkoli je emise protokolu pevně daná, odměny jsou vyraženy až poté, co indexátoři uzavřou své alokace vůči podgraf, které indexovali. Proto se počet odměn v jednotlivých epochách mění (tj. během některých epoch mohli indexátoři kolektivně uzavřít alokace, které byly otevřené mnoho dní).
-
+
### Epochs
-In the Epochs section, you can analyze on a per-epoch basis, metrics such as:
+V části Epochy můžete na základě jednotlivých epoch analyzovat metriky, jako jsou:
-- Epoch start or end block
-- Query fees generated and indexing rewards collected during a specific epoch
-- Epoch status, which refers to the query fee collection and distribution and can have different states:
- - The active epoch is the one in which Indexers are currently allocating stake and collecting query fees
- - The settling epochs are the ones in which the state channels are being settled. This means that the Indexers are subject to slashing if the consumers open disputes against them.
- - The distributing epochs are the epochs in which the state channels for the epochs are being settled and Indexers can claim their query fee rebates.
- - The finalized epochs are the epochs that have no query fee rebates left to claim by the Indexers, thus being finalized.
+- Počáteční nebo koncový blok epoch
+- Poplatky za dotazy vygenerované a odměny za indexování vybrané během určité epoch
+- Stav epoch, který se týká výběru a distribuce poplatků za dotaz a může mít různé stavy:
+ - Aktivní epocha je ta, ve které indexéry právě přidělují podíl a vybírají poplatky za dotazy
+ - Epoch zúčtování jsou ty, ve kterých se zúčtovávají stavové kanály. To znamená, že indexátoři podléhají krácení, pokud proti nim spotřebitelé zahájí spory.
+ - Distribuční epochy jsou epochy, ve kterých se vypořádávají státní kanály pro epochy a indexátoři si mohou nárokovat slevy z poplatků za dotazy.
+ - Finalizované epochy jsou epochy, u nichž indexátorům nezbývají žádné slevy z poplatků za dotaz, a jsou tedy finalizované.
-
+
-## Your User Profile
+## Váš uživatelský profil
-Now that we’ve talked about the network stats, let’s move on to your personal profile. Your personal profile is the place for you to see your network activity, no matter how you’re participating on the network. Your crypto wallet will act as your user profile, and with the User Dashboard, you’ll be able to see:
+Nyní, když jsme si řekli něco o statistikách sítě, přejděme k vašemu osobnímu profilu. Váš osobní profil je místem, kde vidíte svou aktivitu v síti, ať už se jí účastníte jakýmkoli způsobem. Vaše kryptopeněženka bude fungovat jako váš uživatelský profil a pomocí uživatelského panelu si ji budete moci prohlédnout:
-### Profile Overview
+### Přehled profilů
-This is where you can see any current actions you took. This is also where you can find your profile information, description, and website (if you added one).
+Zde se zobrazují všechny aktuální akce, které jste provedli. Zde také najdete informace o svém profilu, popis a webové stránky (pokud jste si je přidali).
-
+
-### Subgraphs Tab
+### Tab Podgrafy
-If you click into the Subgraphs tab, you’ll see your published subgraphs. This will not include any subgraphs deployed with the CLI for testing purposes – subgraphs will only show up when they are published to the decentralized network.
+Pokud kliknete na kartu podgrafy, zobrazí se vaše publikované podgrafy. Nebudou zde zahrnuty žádné podgrafy nasazené pomocí CLI pro účely testování - podgrafy se zobrazí až po jejich zveřejnění v decentralizované síti.
-
+
-### Indexing Tab
+### Tab Indexování
-If you click into the Indexing tab, you’ll find a table with all the active and historical allocations towards the subgraphs, as well as charts that you can analyze and see your past performance as an Indexer.
+Pokud kliknete na kartu Indexování, najdete tabulku se všemi aktivními a historickými alokacemi k dílčím grafy a také grafy, které můžete analyzovat a podívat se na svou minulou výkonnost jako indexátor.
-This section will also include details about your net Indexer rewards and net query fees. You’ll see the following metrics:
+Tato část bude také obsahovat podrobnosti o vašich čistých odměnách za indexování a čistých poplatcích za dotazy. Zobrazí se následující metriky:
-- Delegated Stake - the stake from Delegators that can be allocated by you but cannot be slashed
-- Total Query Fees - the total fees that users have paid for queries served by you over time
-- Indexer Rewards - the total amount of Indexer rewards you have received, in GRT
-- Fee Cut - the % of query fee rebates that you will keep when you split with Delegators
-- Rewards Cut - the % of Indexer rewards that you will keep when splitting with Delegators
-- Owned - your deposited stake, which could be slashed for malicious or incorrect behavior
+- Delegovaná sázka – sázka od delegátů, kterou můžete přidělit vy, ale nelze ji snížit
+- Celkové poplatky za dotazy - celkové poplatky, které uživatelé zaplatili za dotazy, které jste obsloužili v průběhu času
+- Odměny indexátora - celková částka odměn indexátora, kterou jste obdrželi, v GRT
+- Fee Cut - % slevy z poplatku za dotaz, které si ponecháte při rozdělení s delegáty
+- Rozdělení odměn - % odměn indexátorů, které si ponecháte při dělení s delegáty
+- Ve vlastnictví - váš vložený vklad, který může být snížen za škodlivé nebo nesprávné chování
-
+
-### Delegating Tab
+### Tab Delegování
-Delegators are important to the Graph Network. A Delegator must use their knowledge to choose an Indexer that will provide a healthy return on rewards. Here you can find details of your active and historical delegations, along with the metrics of the Indexers that you delegated towards.
+Delegáti jsou pro síť Graf důležití. Delegát musí využít svých znalostí k výběru indexátora, který mu zajistí zdravou návratnost odměn. Zde najdete podrobnosti o svých aktivních a historických delegacích spolu s metrikami Indexátorů, ke kterým jste delegovali.
-In the first half of the page, you can see your delegation chart, as well as the rewards-only chart. To the left, you can see the KPIs that reflect your current delegation metrics.
+V první polovině stránky vidíte graf delegování a také graf odměn. Vlevo vidíte klíčové ukazatele výkonnosti, které odrážejí vaše aktuální metriky delegování.
-The Delegator metrics you’ll see here in this tab include:
+Metriky delegáta, které uvidíte na této tab, zahrnují:
-- Total delegation rewards
-- Total unrealized rewards
-- Total realized rewards
+- Celkové odměny za delegování
+- Nerealizované odměny celkem
+- Celkové realizované odměny
-In the second half of the page, you have the delegations table. Here you can see the Indexers that you delegated towards, as well as their details (such as rewards cuts, cooldown, etc).
+V druhé polovině stránky je tabulka delegací. Zde vidíte indexátory, které jste delegovali, a také jejich podrobnosti (například snížení odměn, zkrácení doby platnosti atd.).
-With the buttons on the right side of the table, you can manage your delegation - delegate more, undelegate, or withdraw your delegation after the thawing period.
+Pomocí tlačítek na pravé straně tabulky můžete spravovat delegování - delegovat více, zrušit delegování nebo stáhnout delegování po uplynutí doby rozmrazení.
-Keep in mind that this chart is horizontally scrollable, so if you scroll all the way to the right, you can also see the status of your delegation (delegating, undelegating, withdrawable).
+Nezapomeňte, že tento graf lze horizontálně posouvat, takže pokud se posunete úplně doprava, uvidíte také stav svého delegování (delegování, nedelegování, odvolání).
-
+
-### Curating Tab
+### Tab Kurátorství
-In the Curation tab, you’ll find all the subgraphs you’re signaling on (thus enabling you to receive query fees). Signaling allows Curators to highlight to Indexers which subgraphs are valuable and trustworthy, thus signaling that they need to be indexed on.
+Na kartě Kurátorství najdete všechny dílčí grafy, na které signalizujete (a které vám tak umožňují přijímat poplatky za dotazy). Signalizace umožňuje kurátorům upozornit indexátory na to, které podgrafy jsou hodnotné a důvěryhodné, a tím signalizovat, že je třeba je indexovat.
-Within this tab, you’ll find an overview of:
+Na této tab najdete přehled:
-- All the subgraphs you're curating on with signal details
-- Share totals per subgraph
-- Query rewards per subgraph
-- Updated at date details
+- Všechny dílčí podgrafy, na kterých kurátor pracuje, s podrobnostmi o signálu
+- Celkové podíly na podgraf
+- Odměny za dotaz na podgraf
+- Aktualizováno v detailu data
-
+
## Your Profile Settings
diff --git a/website/pages/cs/network/indexing.mdx b/website/pages/cs/network/indexing.mdx
index 9bdc2fb2eb7e..61567ffe302a 100644
--- a/website/pages/cs/network/indexing.mdx
+++ b/website/pages/cs/network/indexing.mdx
@@ -1,48 +1,48 @@
---
-title: Indexing
+title: Indexování
---
-Indexers are node operators in The Graph Network that stake Graph Tokens (GRT) in order to provide indexing and query processing services. Indexers earn query fees and indexing rewards for their services. They also earn query fees that are rebated according to an exponential rebate function.
+Indexery jsou operátoři uzlů v síti Graf, kteří sázejí graf tokeny (GRT), aby mohli poskytovat služby indexování a zpracování dotazů. Indexátoři za své služby získávají poplatky za dotazy a odměny za indexování. Získávají také poplatky za dotazy, které jsou vráceny podle exponenciální funkce vrácení.
-GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly. Indexers also earn rewards for delegated stake from Delegators, to contribute to the network.
+GRT, který je v protokolu založen, podléhá období rozmrazování a může být zkrácen, pokud jsou indexátory škodlivé a poskytují aplikacím nesprávná data nebo pokud indexují nesprávně. Indexátoři také získávají odměny za delegované sázky od delegátů, aby přispěli do sítě.
-Indexers select subgraphs to index based on the subgraph’s curation signal, where Curators stake GRT in order to indicate which subgraphs are high-quality and should be prioritized. Consumers (eg. applications) can also set parameters for which Indexers process queries for their subgraphs and set preferences for query fee pricing.
+Indexátory vybírají podgrafy k indexování na základě signálu kurátorů podgrafů, přičemž kurátoři sázejí na GRT, aby určili, které podgrafy jsou vysoce kvalitní a měly by být upřednostněny. Spotřebitelé (např. aplikace) mohou také nastavit parametry, podle kterých indexátoři zpracovávají dotazy pro jejich podgrafy, a nastavit preference pro stanovení ceny poplatků za dotazy.
## FAQ
-### What is the minimum stake required to be an Indexer on the network?
+### Jaký je minimální podíl potřebný k tomu, abyste se mohli stát indexátorem v síti?
-The minimum stake for an Indexer is currently set to 100K GRT.
+Minimální vklad pro indexátora je v současné době nastaven na 100k GRT.
-### What are the revenue streams for an Indexer?
+### Jaké jsou toky příjmů pro indexátora?
-**Query fee rebates** - Payments for serving queries on the network. These payments are mediated via state channels between an Indexer and a gateway. Each query request from a gateway contains a payment and the corresponding response a proof of query result validity.
+**Slevy z poplatků za dotazy** - Platby za obsluhu dotazů v síti. Tyto platby jsou zprostředkovány prostřednictvím stavových kanálů mezi indexerem a bránou. Každý dotazový požadavek z brány obsahuje platbu a odpovídající odpověď doklad o platnosti výsledku dotazu.
-**Indexing rewards** - Generated via a 3% annual protocol wide inflation, the indexing rewards are distributed to Indexers who are indexing subgraph deployments for the network.
+**Odměny za indexování** - Odměny za indexování, generované prostřednictvím 3% roční inflace v rámci celého protokolu, jsou rozdělovány indexátorům, kteří indexují rozmístění podgrafů pro síť.
-### How are indexing rewards distributed?
+### Jak se rozdělují odměny za indexaci?
-Indexing rewards come from protocol inflation which is set to 3% annual issuance. They are distributed across subgraphs based on the proportion of all curation signal on each, then distributed proportionally to Indexers based on their allocated stake on that subgraph. **An allocation must be closed with a valid proof of indexing (POI) that meets the standards set by the arbitration charter in order to be eligible for rewards.**
+Odměny za indexaci pocházejí z protokolární inflace, která je stanovena na 3 % ročně. Rozdělují se mezi podgrafy na základě podílu všech kurátorských signálů na každém z nich a poté se poměrně rozdělí indexátorům na základě jejich přiděleného podílu na daném podgrafu. **Alokace musí být uzavřena platným důkazem indexace (POI), který splňuje standardy stanovené rozhodčí chartou, aby bylo možné získat odměny.**
-Numerous tools have been created by the community for calculating rewards; you'll find a collection of them organized in the [Community Guides collection](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). You can also find an up to date list of tools in the #Delegators and #Indexers channels on the [Discord server](https://discord.gg/graphprotocol). Here we link a [recommended allocation optimiser](https://github.com/graphprotocol/AllocationOpt.jl) integrated with the indexer software stack.
+Komunita vytvořila řadu nástrojů pro výpočet odměn; jejich sbírku najdete ve sbírce [Průvodci komunity](https://www.notion.so/Community-Guides-abbb10f4dba040d5ba81648ca093e70c). Aktuální seznam nástrojů najdete také v kanálech #Delegators a #Indexers na serveru [Discord](https://discord.gg/graphprotocol). Zde uvádíme odkaz na [doporučený optimalizátor alokace](https://github.com/graphprotocol/AllocationOpt.jl) integrovaný se softwarovým zásobníkem indexátorů.
-### What is a proof of indexing (POI)?
+### Co je Důkaz indexování (POI)?
-POIs are used in the network to verify that an Indexer is indexing the subgraphs they have allocated on. A POI for the first block of the current epoch must be submitted when closing an allocation for that allocation to be eligible for indexing rewards. A POI for a block is a digest for all entity store transactions for a specific subgraph deployment up to and including that block.
+V síti se používají Proofy indexování (POI) k ověření, zda indexátor skutečně indexuje podgrafy, na které má alokovanou kapacitu. Pro uzavření alokace a možnost získat odměny za indexování je nutné při uzavírání alokace předložit POI pro první blok aktuální epochy. POI pro daný blok je souhrn všech transakcí v úložišti entit pro konkrétní nasazení podgrafu, a to až do tohoto bloku včetně.
-### When are indexing rewards distributed?
+### Kdy se rozdělují odměny za indexaci?
-Allocations are continuously accruing rewards while they're active and allocated within 28 epochs. Rewards are collected by the Indexers, and distributed whenever their allocations are closed. That happens either manually, whenever the Indexer wants to force close them, or after 28 epochs a Delegator can close the allocation for the Indexer, but this results in no rewards. 28 epochs is the max allocation lifetime (right now, one epoch lasts for ~24h).
+Za přidělení se průběžně připisují odměny, dokud jsou aktivní a přidělené během 28 epoch. Odměny jsou shromažďovány indexátory a rozdělovány vždy, když jsou jejich alokace uzavřeny. To se děje buď ručně, kdykoli je chce indexátor násilně uzavřít, nebo po 28 epochách může alokaci za indexátora uzavřít delegát, což však nevede k žádným odměnám. 28 epoch je maximální doba životnosti alokace (právě teď trvá jedna epocha ~24 hodin).
-### Can pending indexing rewards be monitored?
+### Lze sledovat čekající odměny za indexaci?
-The RewardsManager contract has a read-only [getRewards](https://github.com/graphprotocol/contracts/blob/master/contracts/rewards/RewardsManager.sol#L317) function that can be used to check the pending rewards for a specific allocation.
+Smlouva RewardsManager obsahuje funkci [getRewards](https://github.com/graphprotocol/contracts/blob/master/contracts/rewards/RewardsManager.sol#L317) pouze pro čtení, kterou lze použít ke zjištění čekajících odměn pro konkrétní příděl.
-Many of the community-made dashboards include pending rewards values and they can be easily checked manually by following these steps:
+Mnoho informačních panelů vytvořených komunitou obsahuje hodnoty čekajících odměn a lze je snadno zkontrolovat ručně podle následujících kroků:
-1. Query the [mainnet subgraph](https://thegraph.com/hosted-service/subgraph/graphprotocol/graph-network-mainnet) to get the IDs for all active allocations:
+1. Dotazem na podgraf [mainnet](https://thegraph.com/hosted-service/subgraph/graphprotocol/graph-network-mainnet) získáte ID všech aktivních alokací:
```graphql
query indexerAllocations {
@@ -58,139 +58,139 @@ query indexerAllocations {
}
```
-Use Etherscan to call `getRewards()`:
+Pomocí funkce Etherscan zavolejte `getRewards()`:
-- Navigate to [Etherscan interface to Rewards contract](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
+- Přejděte na [Etherscan rozhraní na smlouvu odměny](https://etherscan.io/address/0x9Ac758AB77733b4150A901ebd659cbF8cB93ED66#readProxyContract)
-* To call `getRewards()`:
- - Expand the **10. getRewards** dropdown.
- - Enter the **allocationID** in the input.
- - Click the **Query** button.
+* Volání funkce `getRewards()`:
+ - Rozbalte rozevírací seznam **10. getRewards**.
+ - Do vstupu zadejte **allocationID**.
+ - Klikněte na tlačítko **Dotaz**.
-### What are disputes and where can I view them?
+### Co jsou to spory a kde si je mohu prohlédnout?
-Indexer's queries and allocations can both be disputed on The Graph during the dispute period. The dispute period varies, depending on the type of dispute. Queries/attestations have 7 epochs dispute window, whereas allocations have 56 epochs. After these periods pass, disputes cannot be opened against either of allocations or queries. When a dispute is opened, a deposit of a minimum of 10,000 GRT is required by the Fishermen, which will be locked until the dispute is finalized and a resolution has been given. Fisherman are any network participants that open disputes.
+Dotazy indexátoru i alokace lze v grafu zpochybnit během sporného období. Období sporu se liší v závislosti na typu sporu. Dotazy/atesty mají 7 epochové sporné okno, zatímco alokace mají 56 epoch. Po uplynutí těchto období nelze zahájit spor ani proti alokacím, ani proti dotazům. Při zahájení sporu musí rybáři složit zálohu v minimální výši 10,000 GRT, která bude zablokována až do ukončení sporu a vydání rozhodnutí. Rybáři jsou všichni účastníci sítě, kteří otevírají spory.
-Disputes have **three** possible outcomes, so does the deposit of the Fishermen.
+Spory mají **tři** možné výsledky, stejně tak vklad rybářů.
-- If the dispute is rejected, the GRT deposited by the Fishermen will be burned, and the disputed Indexer will not be slashed.
-- If the dispute is settled as a draw, the Fishermen's deposit will be returned, and the disputed Indexer will not be slashed.
-- If the dispute is accepted, the GRT deposited by the Fishermen will be returned, the disputed Indexer will be slashed and the Fishermen will earn 50% of the slashed GRT.
+- Pokud bude spor zamítnut, GRT složené rybáři budou spáleny a sporný indexátor nebude krácen.
+- Pokud je spor vyřešen nerozhodně, bude Fishermen's vklad vrácen a sporný indexátor nebude penalizován snížením stake.
+- Pokud je spor uznán, bude Fishermen's vklad vrácen, sporný indexátor bude penalizován snížením stake a Fishermen obdrží 50 % sníženého stake.
-Disputes can be viewed in the UI in an Indexer's profile page under the `Disputes` tab.
+Spory lze zobrazit v UI na stránce profilu indexátora na kartě `Spory`.
-### What are query fee rebates and when are they distributed?
+### Co jsou to slevy z poplatků za dotaz a kdy se rozdělují?
-Query fees are collected by the gateway and distributed to indexers according to the exponential rebate function (see GIP [here](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). The exponential rebate function is proposed as a way to ensure indexers achieve the best outcome by faithfully serving queries. It works by incentivizing Indexers to allocate a large amount of stake (which can be slashed for erring when serving a query) relative to the amount of query fees they may collect.
+Poplatky za dotazy vybírá brána a rozděluje je indexátorům podle exponenciální funkce rabatu (viz GIP [zde](https://forum.thegraph.com/t/gip-0051-exponential-query-fee-rebates-for-indexers/4162)). Exponenciální funkce rabatu je navržena jako způsob, jak zajistit, aby indexátory dosáhly nejlepšího výsledku věrným obsloužením dotazů. Funguje tak, že motivuje indexátory, aby přidělovali velké množství podílu (který může být snížen za chybu při obsluze dotazu) v poměru k výši poplatků za dotazy, které mohou inkasovat.
-Once an allocation has been closed the rebates are available to be claimed by the Indexer. Upon claiming, the query fee rebates are distributed to the Indexer and their Delegators based on the query fee cut and the exponential rebate function.
+Po uzavření přídělu může indexátor požádat o slevy. Po uplatnění nároku jsou slevy z poplatku za dotaz rozděleny mezi indexátora a jeho delegáty na základě snížení poplatku za dotaz a exponenciální funkce slevy.
-### What is query fee cut and indexing reward cut?
+### Co je to snížení poplatku za dotaz a snížení odměny za indexaci?
-The `queryFeeCut` and `indexingRewardCut` values are delegation parameters that the Indexer may set along with cooldownBlocks to control the distribution of GRT between the Indexer and their Delegators. See the last steps in [Staking in the Protocol](/network/indexing#stake-in-the-protocol) for instructions on setting the delegation parameters.
+Hodnoty `queryFeeCut` a `indexingRewardCut` jsou parametry delegování, které může indexátor nastavit spolu s bloky cooldownBlocks a řídit tak rozdělení GRT mezi indexátor a jeho delegáty. Pokyny k nastavení parametrů delegování naleznete v posledních krocích v části [Zadání protokolu](/network/indexing#stake-in-the-protocol).
-- **queryFeeCut** - the % of query fee rebates that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the query fees earned when an allocation is closed with the other 5% going to the Delegators.
+- **queryFeeCut** - % slev z poplatků za dotaz, které budou rozděleny mezi indexátory. Pokud je tato hodnota nastavena na 95%, obdrží indexátor 95% poplatků za dotaz získaných při uzavření přídělu a zbylých 5% připadne delegátům.
-- **indexingRewardCut** - the % of indexing rewards that will be distributed to the Indexer. If this is set to 95%, the Indexer will receive 95% of the indexing rewards when an allocation is closed and the Delegators will split the other 5%.
+- **indexingRewardCut** - % odměn za indexování, které budou rozděleny indexátoru. Pokud je tato hodnota nastavena na 95 %, obdrží indexátor při uzavření přídělu 95 % odměn za indexování a zbylých 5 % si rozdělí delegáti.
-### How do Indexers know which subgraphs to index?
+### Jak indexátory poznají, které podgrafy mají indexovat?
-Indexers may differentiate themselves by applying advanced techniques for making subgraph indexing decisions but to give a general idea we'll discuss several key metrics used to evaluate subgraphs in the network:
+Indexátory se mohou odlišovat použitím pokročilých technik pro rozhodování o indexaci podgrafů, ale pro obecnou představu probereme několik klíčových metrik používaných k hodnocení podgrafů v síti:
-- **Curation signal** - The proportion of network curation signal applied to a particular subgraph is a good indicator of the interest in that subgraph, especially during the bootstrap phase when query voluming is ramping up.
+- **Signál kurátorství** - Podíl signálu kurátorství sítě aplikovaného na určitý podgraf je dobrým ukazatelem zájmu o tento podgraf, zejména během zaváděcí fáze, kdy se zvyšuje objem dotazů.
-- **Query fees collected** - The historical data for volume of query fees collected for a specific subgraph is a good indicator of future demand.
+- **Vybrané poplatky za dotazy** - Historické údaje o objemu vybraných poplatků za dotazy pro určitý podgraf jsou dobrým ukazatelem budoucí poptávky.
-- **Amount staked** - Monitoring the behavior of other Indexers or looking at proportions of total stake allocated towards specific subgraphs can allow an Indexer to monitor the supply side for subgraph queries to identify subgraphs that the network is showing confidence in or subgraphs that may show a need for more supply.
+- **Amount staked** - Sledování chování ostatních indexátorů nebo podílů celkového vkladu přiděleného konkrétním podgrafům může indexátoru umožnit sledovat stranu nabídky pro dotazy na podgrafy a identifikovat podgrafy, kterým síť důvěřuje, nebo podgrafy, které mohou vykazovat potřebu větší nabídky.
-- **Subgraphs with no indexing rewards** - Some subgraphs do not generate indexing rewards mainly because they are using unsupported features like IPFS or because they are querying another network outside of mainnet. You will see a message on a subgraph if it is not generating indexing rewards.
+- **Podgrafy bez odměn za indexování** - Některé podgrafy negenerují odměny za indexování především proto, že používají nepodporované funkce, jako je IPFS, nebo protože se dotazují na jinou síť mimo hlavní síť. Pokud podgraf negeneruje odměny za indexování, zobrazí se u něj tato zpráva.
-### What are the hardware requirements?
+### Jaké jsou požadavky na hardware?
-- **Small** - Enough to get started indexing several subgraphs, will likely need to be expanded.
-- **Standard** - Default setup, this is what is used in the example k8s/terraform deployment manifests.
-- **Medium** - Production Indexer supporting 100 subgraphs and 200-500 requests per second.
-- **Large** - Prepared to index all currently used subgraphs and serve requests for the related traffic.
+- **Malý** - Dostatečný pro začátek indexování několika podgrafů, pravděpodobně bude třeba jej rozšířit.
+- **Standard** - Výchozí nastavení, které je použito v ukázkových manifestech nasazení k8s/terraform.
+- **Střední** - produkční indexer podporující 100 podgrafů a 200-500 požadavků za sekundu.
+- **Large** - Připraveno k indexování všech aktuálně nepoužívaných příbuzných podgrafů.
-| Setup | Postgres
(CPUs) | Postgres
(memory in GBs) | Postgres
(disk in TBs) | VMs
(CPUs) | VMs
(memory in GBs) |
+| Nastavení | Postgres
(CPUs) | Postgres
(paměť v GBs) | Postgres
(disk v TBs) | VMs
(CPUs) | VMs
(paměť v GBs) |
| --- | :-: | :-: | :-: | :-: | :-: |
-| Small | 4 | 8 | 1 | 4 | 16 |
+| Malé | 4 | 8 | 1 | 4 | 16 |
| Standard | 8 | 30 | 1 | 12 | 48 |
-| Medium | 16 | 64 | 2 | 32 | 64 |
-| Large | 72 | 468 | 3.5 | 48 | 184 |
+| Střední | 16 | 64 | 2 | 32 | 64 |
+| Velký | 72 | 468 | 3.5 | 48 | 184 |
-### What are some basic security precautions an Indexer should take?
+### Jaká jsou základní bezpečnostní opatření, která by měl indexátor přijmout?
-- **Operator wallet** - Setting up an operator wallet is an important precaution because it allows an Indexer to maintain separation between their keys that control stake and those that are in control of day-to-day operations. See [Stake in Protocol](/network/indexing#stake-in-the-protocol) for instructions.
+- **Peněženka operátora** - Nastavení peněženky operátora je důležitým opatřením, protože umožňuje indexátorovi udržovat oddělení mezi klíči, které kontrolují sázky, a klíči, které řídí každodenní operace. Pokyny naleznete v části [Podíl na protokolu](/network/indexing#stake-in-the-protocol).
-- **Firewall** - Only the Indexer service needs to be exposed publicly and particular attention should be paid to locking down admin ports and database access: the Graph Node JSON-RPC endpoint (default port: 8030), the Indexer management API endpoint (default port: 18000), and the Postgres database endpoint (default port: 5432) should not be exposed.
+- **Firewall** - Pouze služba Indexer musí být vystavena veřejně a zvláštní pozornost by měla být věnována uzamčení portů pro správu a přístupu k databázi: koncový bod JSON-RPC uzlu Graf (výchozí port: 8030), koncový bod API pro správu Indexeru (výchozí port: 18000) a koncový bod databáze Postgres (výchozí port: 5432) by neměly být vystaveny.
-## Infrastructure
+## Infrastruktura
-At the center of an Indexer's infrastructure is the Graph Node which monitors the indexed networks, extracts and loads data per a subgraph definition and serves it as a [GraphQL API](/about/#how-the-graph-works). The Graph Node needs to be connected to an endpoint exposing data from each indexed network; an IPFS node for sourcing data; a PostgreSQL database for its store; and Indexer components which facilitate its interactions with the network.
+Centrem infrastruktury indexeru je uzel Graf, který monitoruje indexované sítě, extrahuje a načítá data podle definice podgrafu a poskytuje je jako [GraphQL API](/about/#how-the-graph-works). Uzel Graf musí být připojen ke koncovému bodu vystavujícímu data z každé indexované sítě, uzlu IPFS pro získávání dat, databázi PostgreSQL pro jejich ukládání a komponentám Indexeru, které usnadňují jeho interakci se sítí.
-- **PostgreSQL database** - The main store for the Graph Node, this is where subgraph data is stored. The Indexer service and agent also use the database to store state channel data, cost models, indexing rules, and allocation actions.
+- **Databáze PostgreSQL** - Hlavní úložiště pro uzel Graf kde jsou uložena data dílčích grafů. Služba Indexer a agent také používají databázi k ukládání dat stavového kanálu, nákladových modelů, indexačních pravidel a alokačních akcí.
-- **Data endpoint** - For EVM-compatible networks, Graph Node needs to be connected to an endpoint that exposes an EVM-compatible JSON-RPC API. This may take the form of a single client or it could be a more complex setup that load balances across multiple. It's important to be aware that certain subgraphs will require particular client capabilities such as archive mode and/or the parity tracing API.
+- **Datový koncový bod** - Pro sítě kompatibilní s EVM musí být graf uzel připojen ke koncovému bodu, který vystavuje API JSON-RPC kompatibilní s EVM. To může mít podobu jediného klienta nebo může jít o složitější nastavení, které vyrovnává zátěž mezi více. Je důležité si uvědomit, že některé dílčí grafy budou vyžadovat konkrétní schopnosti klienta, jako je archivační režim a/nebo API pro sledování parity.
-- **IPFS node (version less than 5)** - Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network Indexers do not need to host their own IPFS node, an IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+- **Vuzel IPFS (verze menší než 5)** - Metadata nasazení podgrafů jsou uložena v síti IPFS. Uzel Graf přistupuje během nasazení podgrafu primárně k uzlu IPFS, aby načetl manifest podgrafu a všechny propojené soubory. Síťové indexátory nemusí hostovat vlastní uzel IPFS, uzel IPFS pro síť je hostován na adrese https://ipfs.network.thegraph.com.
-- **Indexer service** - Handles all required external communications with the network. Shares cost models and indexing statuses, passes query requests from gateways on to a Graph Node, and manages the query payments via state channels with the gateway.
+- **Služba indexeru** - Zpracovává veškerou požadovanou externí komunikaci se sítí. Sdílí nákladové modely a stavy indexace, předává požadavky na dotazy z bran na uzel Graga spravuje platby za dotazy prostřednictvím stavových kanálů s branou.
-- **Indexer agent** - Facilitates the Indexers interactions on chain including registering on the network, managing subgraph deployments to its Graph Node/s, and managing allocations.
+- **Indexer agent** - Usnadňuje interakce indexerů v řetězci, včetně registrace v síti, správy nasazení podgrafů do jejich grafových uzlů a správy alokací.
-- **Prometheus metrics server** - The Graph Node and Indexer components log their metrics to the metrics server.
+- **Server metrik Prometheus** - Komponenty Uzel grafu a Indexer zaznamenávají své metriky na metrický server.
-Note: To support agile scaling, it is recommended that query and indexing concerns are separated between different sets of nodes: query nodes and index nodes.
+Poznámka: Pro podporu agilního škálování se doporučuje oddělit dotazování a indexování mezi různé sady uzlů: dotazovací uzly a indexovací uzly.
-### Ports overview
+### Přehled portů
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC and the Indexer management endpoints detailed below.
+> **Důležité**: Dávejte pozor na veřejné vystavování portů - **administrační porty** by měly být uzamčeny. To zahrnuje koncové body JSON-RPC uzlu Graf a koncové body správy Indexeru, které jsou podrobně popsány níže.
-#### Graph Node
+#### Uzel Graf
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
+| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server
(for subgraph queries) | /subgraphs/id/...
/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS
(for subgraph subscriptions) | /subgraphs/id/...
/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC
(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| 8000 | GraphQL HTTP server
(pro dotazy podgrafy) | /subgraphs/id/...
/subgraphs/name/.../... | --http-port | - |
+| 8001 | GraphQL WS
(pro odběry podgrafů) | /subgraphs/id/...
/subgraphs/name/.../... | --ws-port | - |
+| 8020 | JSON-RPC
(pro správu nasazení) | / | --admin-port | - |
+| 8030 | Stav indexování podgrafů API | /graphql | --index-node-port | - |
+| 8040 | Metriky Prometheus | /metrics | --metrics-port | - |
-#### Indexer Service
+#### Služba Indexer
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
+| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
| --- | --- | --- | --- | --- |
-| 7600 | GraphQL HTTP server
(for paid subgraph queries) | /subgraphs/id/...
/status
/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
-| 7300 | Prometheus metrics | /metrics | --metrics-port | - |
+| 7600 | GraphQL HTTP server
(pro placené dotazy na podgrafy) | /subgraphs/id/...
/status
/channel-messages-inbox | --port | `INDEXER_SERVICE_PORT` |
+| 7300 | Metriky Prometheus | /metrics | --metrics-port | - |
-#### Indexer Agent
+#### Agent indexátoru
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
-| ---- | ---------------------- | ------ | ------------------------- | --------------------------------------- |
-| 8000 | Indexer management API | / | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
+| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
+| ---- | ------------------------- | ----- | ------------------------- | --------------------------------------- |
+| 8000 | API pro správu indexátoru | / | --indexer-management-port | `INDEXER_AGENT_INDEXER_MANAGEMENT_PORT` |
-### Setup server infrastructure using Terraform on Google Cloud
+### Nastavení serverové infrastruktury pomocí Terraformu ve Google Cloud
-> Note: Indexers can alternatively use AWS, Microsoft Azure, or Alibaba.
+> Poznámka: Indexéry mohou alternativně používat AWS, Microsoft Azure nebo Alibaba.
-#### Install prerequisites
+#### Instalace předpokladů
- Google Cloud SDK
-- Kubectl command line tool
+- Nástroj příkazového řádku Kubectl
- Terraform
-#### Create a Google Cloud Project
+#### Vytvoření projektu Google Cloud
-- Clone or navigate to the Indexer repository.
+- Klonujte nebo přejděte do úložiště Indexer.
-- Navigate to the ./terraform directory, this is where all commands should be executed.
+- Přejděte do adresáře ./terraform, kde by se měly spouštět všechny příkazy.
```sh
cd terraform
```
-- Authenticate with Google Cloud and create a new project.
+- Ověřte se pomocí služby Google Cloud a vytvořte nový projekt.
```sh
gcloud auth login
@@ -198,9 +198,9 @@ project=
gcloud projects create --enable-cloud-apis $project
```
-- Use the Google Cloud Console's billing page to enable billing for the new project.
+- Pomocí fakturační stránky konzoly Google Cloud Console povolte fakturaci pro nový projekt.
-- Create a Google Cloud configuration.
+- Vytvořte konfiguraci služby Google Cloud.
```sh
proj_id=$(gcloud projects list --format='get(project_id)' --filter="name=$project")
@@ -210,7 +210,7 @@ gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
```
-- Enable required Google Cloud APIs.
+- Povolte požadované Google Cloud API.
```sh
gcloud services enable compute.googleapis.com
@@ -219,7 +219,7 @@ gcloud services enable servicenetworking.googleapis.com
gcloud services enable sqladmin.googleapis.com
```
-- Create a service account.
+- Vytvoření účtu služby.
```sh
svc_name=
@@ -237,7 +237,7 @@ gcloud projects add-iam-policy-binding $proj_id \
--role roles/editor
```
-- Enable peering between database and Kubernetes cluster that will be created in the next step.
+- Povolte peering mezi databází a clusterem Kubernetes, který bude vytvořen v dalším kroku.
```sh
gcloud compute addresses create google-managed-services-default \
@@ -251,7 +251,7 @@ gcloud services vpc-peerings connect \
--ranges=google-managed-services-default
```
-- Create minimal terraform configuration file (update as needed).
+- Vytvořte minimální konfigurační soubor terraformu (aktualizujte jej podle potřeby).
```sh
indexer=
@@ -262,11 +262,11 @@ database_password = ""
EOF
```
-#### Use Terraform to create infrastructure
+#### Použití nástroje Terraform k vytvoření infrastruktury
-Before running any commands, read through [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) and create a file `terraform.tfvars` in this directory (or modify the one we created in the last step). For each variable where you want to override the default, or where you need to set a value, enter a setting into `terraform.tfvars`.
+Před spuštěním jakýchkoli příkazů si přečtěte soubor [variables.tf](https://github.com/graphprotocol/indexer/blob/main/terraform/variables.tf) a vytvořte v tomto adresáři soubor `terraform.tfvars` (nebo upravte soubor vytvořený v minulém kroku). Pro každou proměnnou, u které chcete přepsat výchozí hodnotu nebo u které potřebujete nastavit hodnotu, zadejte nastavení do `terraform.tfvars`.
-- Run the following commands to create the infrastructure.
+- Pro vytvoření infrastruktury spusťte následující příkazy.
```sh
# Install required plugins
@@ -279,7 +279,7 @@ terraform plan
terraform apply
```
-Download credentials for the new cluster into `~/.kube/config` and set it as your default context.
+Stáhněte pověření pro nový cluster do souboru `~/.kubeconfig` a nastavte jej jako výchozí kontext.
```sh
gcloud container clusters get-credentials $indexer
@@ -287,21 +287,21 @@ kubectl config use-context $(kubectl config get-contexts --output='name'
| grep $indexer)
```
-#### Creating the Kubernetes components for the Indexer
+#### Vytvoření komponent Kubernetes pro Indexer
-- Copy the directory `k8s/overlays` to a new directory `$dir,` and adjust the `bases` entry in `$dir/kustomization.yaml` so that it points to the directory `k8s/base`.
+- Zkopírujte adresář `k8s/overlays` do nového adresáře `$dir,` a upravte položku `bases` v `$dir/kustomization.yaml` tak, aby ukazovala na adresář `k8s/base`.
-- Read through all the files in `$dir` and adjust any values as indicated in the comments.
+- Přečtěte si všechny soubory v `$dir` a upravte všechny hodnoty uvedené v komentářích.
-Deploy all resources with `kubectl apply -k $dir`.
+Všechny prostředky nasadíte pomocí `kubectl apply -k $dir`.
-### Graph Node
+### Uzel Grafu
-[Graph Node](https://github.com/graphprotocol/graph-node) is an open source Rust implementation that event sources the Ethereum blockchain to deterministically update a data store that can be queried via the GraphQL endpoint. Developers use subgraphs to define their schema, and a set of mappings for transforming the data sourced from the block chain and the Graph Node handles syncing the entire chain, monitoring for new blocks, and serving it via a GraphQL endpoint.
+[Uzel Graf](https://github.com/graphprotocol/graph-node) je open source implementace Rust, která využívá zdrojové kódy událostí v blockchainu Ethereum k deterministické aktualizaci datového úložiště, na které se lze dotazovat prostřednictvím koncového bodu GraphQL. Vývojáři používají podgrafy k definici svého schématu a sadu mapování pro transformaci dat získaných z blokového řetězce a Uzel Graf se stará o synchronizaci celého řetězce, monitorování nových bloků a jejich obsluhu prostřednictvím koncového bodu GraphQL.
-#### Getting started from source
+#### Začínáme od zdroje
-#### Install prerequisites
+#### Instalace předpokladů
- **Rust**
@@ -309,15 +309,15 @@ Deploy all resources with `kubectl apply -k $dir`.
- **IPFS**
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Další požadavky pro uživatele Ubuntu** - Pro spuštění Uzel Graf v Ubuntu může být potřeba několik dalších balíčků.
```sh
sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
```
-#### Setup
+#### Nastavení
-1. Start a PostgreSQL database server
+1. Spuštění databázového serveru PostgreSQL
```sh
initdb -D .postgres
@@ -325,9 +325,9 @@ pg_ctl -D .postgres -l logfile start
createdb graph-node
```
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Klonujte repozitář [Uzel Graf](https://github.com/graphprotocol/graph-node) a sestavte zdrojový kód spuštěním příkazu `cargo build`
-3. Now that all the dependencies are setup, start the Graph Node:
+3. Nyní, když jsou všechny závislosti nastaveny, spusťte uzel Graf:
```sh
cargo run -p graph-node --release -- \
@@ -336,48 +336,48 @@ cargo run -p graph-node --release -- \
--ipfs https://ipfs.network.thegraph.com
```
-#### Getting started using Docker
+#### Začínáme používat Docker
-#### Prerequisites
+#### Požadavky
-- **Ethereum node** - By default, the docker compose setup will use mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) to connect to the Ethereum node on your host machine. You can replace this network name and url by updating `docker-compose.yaml`.
+- **Ethereum Uzel** - Ve výchozím nastavení docker compose použije mainnet: [http://host.docker.internal:8545](http://host.docker.internal:8545) pro připojení k uzlu Ethereum na hostitelském počítači. Tento název sítě a url můžete nahradit aktualizací souboru `docker-compose.yaml`.
-#### Setup
+#### Nastavení
-1. Clone Graph Node and navigate to the Docker directory:
+1. Klonujte graf uzel a najděte cestu do adresáře Docker:
```sh
git clone https://github.com/graphprotocol/graph-node
cd graph-node/docker
```
-2. For linux users only - Use the host IP address instead of `host.docker.internal` in the `docker-compose.yaml`using the included script:
+2. Pouze pro uživatele Linux- Použijte IP adresu hostitele místo `host.docker.internal` v `docker-compose.yaml` pomocí přiloženého skript:
```sh
./setup.sh
```
-3. Start a local Graph Node that will connect to your Ethereum endpoint:
+3. Spusťte místní uzel Graf, který se připojí ke koncovému bodu Ethereum:
```sh
docker-compose up
```
-### Indexer components
+### Součásti indexeru
-To successfully participate in the network requires almost constant monitoring and interaction, so we've built a suite of Typescript applications for facilitating an Indexers network participation. There are three Indexer components:
+Úspěšná účast v síti vyžaduje téměř neustálé sledování a interakci, proto jsme vytvořili sadu aplikací Typescript pro usnadnění účasti v síti Indexers. K dispozici jsou tři komponenty Indexer:
-- **Indexer agent** - The agent monitors the network and the Indexer's own infrastructure and manages which subgraph deployments are indexed and allocated towards on chain and how much is allocated towards each.
+- **Agent indexátoru** - Agent monitoruje síť a vlastní infrastrukturu indexátoru a spravuje, která dílčí nasazení jsou indexována a alokována do řetězce a kolik je jim přiděleno.
-- **Indexer service** - The only component that needs to be exposed externally, the service passes on subgraph queries to the graph node, manages state channels for query payments, shares important decision making information to clients like the gateways.
+- **Služba indexeru** - Jediná komponenta, která musí být vystavena externě, služba předává dotazy na podgraf uzlu grafu, spravuje stavové kanály pro platby dotazů, sdílí důležité rozhodovací informace klientům, jako jsou brány.
-- **Indexer CLI** - The command line interface for managing the Indexer agent. It allows Indexers to manage cost models, manual allocations, actions queue, and indexing rules.
+- **Indexer CLI** - Rozhraní příkazového řádku pro správu agenta Indexer. Umožňuje indexátorům spravovat nákladové modely, ruční přidělování, frontu akcí a pravidla indexování.
-#### Getting started
+#### Začínáme
-The Indexer agent and Indexer service should be co-located with your Graph Node infrastructure. There are many ways to set up virtual execution environments for your Indexer components; here we'll explain how to run them on baremetal using NPM packages or source, or via kubernetes and docker on the Google Cloud Kubernetes Engine. If these setup examples do not translate well to your infrastructure there will likely be a community guide to reference, come say hi on [Discord](https://discord.gg/graphprotocol)! Remember to [stake in the protocol](/network/indexing#stake-in-the-protocol) before starting up your Indexer components!
+Agent Indexer a služba Indexer by měly být umístěny společně s infrastrukturou graf uzlu. Existuje mnoho způsobů, jak nastavit virtuální prováděcí prostředí pro komponenty Indexer; zde vysvětlíme, jak je spustit na baremetalu pomocí balíčků NPM nebo zdrojových kódů, nebo pomocí kubernetes a docker na Google Cloud Kubernetes Engine. Pokud se tyto příklady nastavení nedají dobře převést na vaši infrastrukturu, bude pravděpodobně existovat komunitní příručka, na kterou se můžete odkázat, přijďte ji pozdravit na [Discord](https://discord.gg/graphprotocol)! Před spuštěním komponent Indexeru nezapomeňte [zakázat protokol](/network/indexing#stake-in-the-protocol)!
-#### From NPM packages
+#### Z balíčků NPM
```sh
npm install -g @graphprotocol/indexer-service
@@ -400,7 +400,7 @@ graph indexer connect http://localhost:18000/
graph indexer ...
```
-#### From source
+#### Ze zdroje
```sh
# From Repo root directory
@@ -420,16 +420,16 @@ cd packages/indexer-cli
./bin/graph-indexer-cli indexer ...
```
-#### Using docker
+#### Použití docker
-- Pull images from the registry
+- Stažení obrázků z registru
```sh
docker pull ghcr.io/graphprotocol/indexer-service:latest
docker pull ghcr.io/graphprotocol/indexer-agent:latest
```
-Or build images locally from source
+Nebo sestavte obrazy lokálně ze zdrojových kódů
```sh
# Indexer service
@@ -444,24 +444,24 @@ docker build \
-t indexer-agent:latest \
```
-- Run the components
+- Spustit komponenty
```sh
docker run -p 7600:7600 -it indexer-service:latest ...
docker run -p 18000:8000 -it indexer-agent:latest ...
```
-**NOTE**: After starting the containers, the Indexer service should be accessible at [http://localhost:7600](http://localhost:7600) and the Indexer agent should be exposing the Indexer management API at [http://localhost:18000/](http://localhost:18000/).
+**POZNÁMKA**: Po spuštění kontejnerů by měla být služba Indexer dostupná na adrese [http://localhost:7600](http://localhost:7600) a agent Indexer by měl vystavovat API pro správu Indexeru na adrese [http://localhost:18000/](http://localhost:18000/).
-#### Using K8s and Terraform
+#### Použití K8s a Terraform
-See the [Setup Server Infrastructure Using Terraform on Google Cloud](/network/indexing#setup-server-infrastructure-using-terraform-on-google-cloud) section
+Viz část [Nastavení serverové infrastruktury pomocí Terraformu ve službě Google Cloud](/network/indexing#setup-server-infrastructure-using-terraform-on-google-cloud)
-#### Usage
+#### Použití
-> **NOTE**: All runtime configuration variables may be applied either as parameters to the command on startup or using environment variables of the format `COMPONENT_NAME_VARIABLE_NAME`(ex. `INDEXER_AGENT_ETHEREUM`).
+> **POZNÁMKA**: Všechny konfigurační proměnné za běhu mohou být použity buď jako parametry příkazu při spuštění, nebo pomocí proměnných prostředí ve formátu `NÁZEV_PŘÍKAZU_VARIABLE_NAME`(např. `INDEXER_AGENT_ETHEREUM`).
-#### Indexer agent
+#### Agent indexátoru
```sh
graph-indexer-agent start \
@@ -490,7 +490,7 @@ graph-indexer-agent start \
| pino-pretty
```
-#### Indexer service
+#### Služba Indexer
```sh
SERVER_HOST=localhost \
@@ -518,56 +518,56 @@ graph-indexer-service start \
#### Indexer CLI
-The Indexer CLI is a plugin for [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) accessible in the terminal at `graph indexer`.
+Indexer CLI je zásuvný modul pro [`@graphprotocol/graph-cli`](https://www.npmjs.com/package/@graphprotocol/graph-cli) přístupný v terminál na adrese `graf indexer`.
```sh
graph indexer connect http://localhost:18000
graph indexer status
```
-#### Indexer management using Indexer CLI
+#### Správa indexeru pomocí Indexer CLI
-The suggested tool for interacting with the **Indexer Management API** is the **Indexer CLI**, an extension to the **Graph CLI**. The Indexer agent needs input from an Indexer in order to autonomously interact with the network on the behalf of the Indexer. The mechanism for defining Indexer agent behavior are **allocation management** mode and **indexing rules**. Under auto mode, an Indexer can use **indexing rules** to apply their specific strategy for picking subgraphs to index and serve queries for. Rules are managed via a GraphQL API served by the agent and known as the Indexer Management API. Under manual mode, an Indexer can create allocation actions using **actions queue** and explicitly approve them before they get executed. Under oversight mode, **indexing rules** are used to populate **actions queue** and also require explicit approval for execution.
+Navrhovaným nástrojem pro interakci s **Indexer Management API** je **Indexer CLI**, rozšíření **Graph CLI**. Agent Indexer potřebuje vstup od Indexeru, aby mohl autonomně komunikovat se sítí jménem Indexeru. Mechanismem pro definování chování agenta Indexer jsou **režim správy přidělování** a **pravidla indexování**. V automatickém režimu může indexátor použít **indexační pravidla** k použití své specifické strategie pro výběr podgrafů k indexování a obsluze dotazů. Pravidla jsou spravována prostřednictvím GraphQL API obsluhovaného agentem a známého jako rozhraní API pro správu indexátoru. V manuálním režimu může indexátor vytvářet alokační akce pomocí **akční fronty** a explicitně je schvalovat před jejich provedením. V režimu dohledu se k naplnění **akční fronty** používají **indexační pravidla**, která rovněž vyžadují explicitní schválení pro provedení.
-#### Usage
+#### Použití
-The **Indexer CLI** connects to the Indexer agent, typically through port-forwarding, so the CLI does not need to run on the same server or cluster. To help you get started, and to provide some context, the CLI will briefly be described here.
+**Indexer CLI** se připojuje k agentovi Indexer, obvykle prostřednictvím přesměrování portů, takže CLI nemusí běžet na stejném serveru nebo clusteru. Abychom vám usnadnili začátek a poskytli vám určitý kontext, bude zde CLI stručně popsáno.
-- `graph indexer connect ` - Connect to the Indexer management API. Typically the connection to the server is opened via port forwarding, so the CLI can be easily operated remotely. (Example: `kubectl port-forward pod/ 8000:8000`)
+- `graf indexer připojit ` - Připojení k API pro správu indexeru. Obvykle se připojení k serveru otevírá pomocí přesměrování portů, takže CLI lze snadno ovládat na dálku. (Příklad: `kubectl port-forward pod/ 8000:8000`)
-- `graph indexer rules get [options] [ ...]` - Get one or more indexing rules using `all` as the `` to get all rules, or `global` to get the global defaults. An additional argument `--merged` can be used to specify that deployment specific rules are merged with the global rule. This is how they are applied in the Indexer agent.
+- `pravidla indexování grafů získat [možnosti] [ ...]` - Získá jedno nebo více indexovacích pravidel pomocí `all` jako `` pro získání všech pravidel nebo `global` pro získání globálních výchozích hodnot. Pomocí doplňkového argumentu `--merged` lze určit, že pravidla specifická pro nasazení budou sloučena s globálním pravidlem. Takto se použijí v agentu Indexer.
-- `graph indexer rules set [options] ...` - Set one or more indexing rules.
+- `pravidla indexování grafů získat [možnosti] ...` -Nastavení jednoho nebo více pravidel indexování.
-- `graph indexer rules start [options] ` - Start indexing a subgraph deployment if available and set its `decisionBasis` to `always`, so the Indexer agent will always choose to index it. If the global rule is set to always then all available subgraphs on the network will be indexed.
+- `pravidla indexování grafů získat [možnosti] ` - Spustí indexování nasazení podgrafů, pokud je k dispozici, a nastaví jeho `decisionBasis` na `always`, takže agent Indexer vždy zvolí jeho indexování. Pokud je globální pravidlo nastaveno na vždy, pak budou indexovány všechny dostupné podgrafy v síti.
-- `graph indexer rules stop [options] ` - Stop indexing a deployment and set its `decisionBasis` to never, so it will skip this deployment when deciding on deployments to index.
+- `zastavení pravidel indexování grafů [možnosti]` - Zastaví indexování nasazení a nastaví jeho `decisionBasis` na never, takže při rozhodování o nasazeních k indexování toto nasazení přeskočí.
-- `graph indexer rules maybe [options] ` — Set the `decisionBasis` for a deployment to `rules`, so that the Indexer agent will use indexing rules to decide whether to index this deployment.
+- `možná pravidla indexování grafů [možnosti] ` - Nastaví `decisionBasis` pro nasazení na `rules`, takže agent Indexer bude při rozhodování o indexování tohoto nasazení používat pravidla indexování.
-- `graph indexer actions get [options] ` - Fetch one or more actions using `all` or leave `action-id` empty to get all actions. An additonal argument `--status` can be used to print out all actions of a certain status.
+- `Akce indexátoru grafu získají [možnosti] ` - Získá jednu nebo více akcí pomocí `all` nebo ponechá `action-id` prázdné pro získání všech akcí. Přídavný argument `--status` lze použít pro vypsání všech akcí určitého stavu.
-- `graph indexer action queue allocate ` - Queue allocation action
+- `graph indexer action queue allocate ` - Akce přidělení fronty
-- `graph indexer action queue reallocate ` - Queue reallocate action
+- `graph indexer action queue reallocate ` - Akce přerozdělení fronty
-- `graph indexer action queue unallocate ` - Queue unallocate action
+- `graph indexer action queue unallocate ` - Akce odalokování fronty
-- `graph indexer actions cancel [ ...]` - Cancel all action in the queue if id is unspecified, otherwise cancel array of id with space as separator
+- `Akce indexátoru grafů zrušit [ ...]` - Zruší všechny akce ve frontě, pokud není id zadáno, jinak zruší pole id s mezerou jako oddělovačem
-- `graph indexer actions approve [ ...]` - Approve multiple actions for execution
+- `schvalovat akce indexátoru grafů[ ...]` - Schválení více akcí k provedení
-- `graph indexer actions execute approve` - Force the worker to execute approved actions immediately
+- `akce indexátoru grafu provést schválit` - Vynutí, aby pracovník okamžitě provedl schválené akce
-All commands which display rules in the output can choose between the supported output formats (`table`, `yaml`, and `json`) using the `-output` argument.
+Všechny příkazy, které zobrazují pravidla na výstupu, mohou pomocí argumentu `-output` volit mezi podporovanými výstupními formáty (`table`, `yaml` a `json`).
-#### Indexing rules
+#### Pravidla indexování
-Indexing rules can either be applied as global defaults or for specific subgraph deployments using their IDs. The `deployment` and `decisionBasis` fields are mandatory, while all other fields are optional. When an indexing rule has `rules` as the `decisionBasis`, then the Indexer agent will compare non-null threshold values on that rule with values fetched from the network for the corresponding deployment. If the subgraph deployment has values above (or below) any of the thresholds it will be chosen for indexing.
+Pravidla indexování lze použít buď jako globální výchozí, nebo pro konkrétní nasazení podgrafů pomocí jejich ID. Pole `nasazení` a `podklad pro rozhodování` jsou povinná, zatímco všechna ostatní pole jsou nepovinná. Pokud má indexovací pravidlo `pravidla` jako `základnu rozhodování`, pak agent Indexer porovná nenulové prahové hodnoty tohoto pravidla s hodnotami získanými ze sítě pro příslušné nasazení. Pokud má dílčí nasazení grafu hodnoty vyšší (nebo nižší) než některá z prahových hodnot, bude vybráno pro indexaci.
-For example, if the global rule has a `minStake` of **5** (GRT), any subgraph deployment which has more than 5 (GRT) of stake allocated to it will be indexed. Threshold rules include `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake`, and `minAverageQueryFees`.
+Pokud má například globální pravidlo `minStake` hodnotu **5** (GRT), bude indexováno každé nasazení podgrafu, kterému je přiděleno více než 5 (GRT) podílů. Mezi prahová pravidla patří `maxAllocationPercentage`, `minSignal`, `maxSignal`, `minStake` a `minAverageQueryFees`.
-Data model:
+Datový model:
```graphql
type IndexingRule {
@@ -601,7 +601,7 @@ IndexingDecisionBasis {
}
```
-Example usage of indexing rule:
+Příklad použití indexovacího pravidla:
```
graph indexer rules offchain QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
@@ -613,20 +613,20 @@ graph indexer rules stop QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
graph indexer rules delete QmZfeJYR86UARzp9HiXbURWunYgC9ywvPvoePNbuaATrEK
```
-#### Actions queue CLI
+#### Fronta akcí CLI
-The indexer-cli provides an `actions` module for manually working with the action queue. It uses the **Graphql API** hosted by the indexer management server to interact with the actions queue.
+Indexer-cli poskytuje modul `actions` pro ruční práci s frontou akcí. K interakci s frontou akcí používá **Graphql API**, které je hostováno serverem pro správu indexeru.
-The action execution worker will only grab items from the queue to execute if they have `ActionStatus = approved`. In the recommended path actions are added to the queue with ActionStatus = queued, so they must then be approved in order to be executed on-chain. The general flow will look like:
+Pracovník pro provádění akcí převezme položky z fronty k provedení pouze tehdy, pokud mají `ActionStatus = approved`. V doporučené cestě jsou akce přidány do fronty se stavem ActionStatus = queued, takže pak musí být schváleny, aby mohly být provedeny v řetězci. Obecný průběh bude vypadat takto:
-- Action added to the queue by the 3rd party optimizer tool or indexer-cli user
-- Indexer can use the `indexer-cli` to view all queued actions
-- Indexer (or other software) can approve or cancel actions in the queue using the `indexer-cli`. The approve and cancel commands take an array of action ids as input.
-- The execution worker regularly polls the queue for approved actions. It will grab the `approved` actions from the queue, attempt to execute them, and update the values in the db depending on the status of execution to `success` or `failed`.
-- If an action is successful the worker will ensure that there is an indexing rule present that tells the agent how to manage the allocation moving forward, useful when taking manual actions while the agent is in `auto` or `oversight` mode.
-- The indexer can monitor the action queue to see a history of action execution and if needed re-approve and update action items if they failed execution. The action queue provides a history of all actions queued and taken.
+- Akce přidaná do fronty nástrojem optimalizace třetí strany nebo uživatelem indexer-cli
+- Indexer může pomocí `indexer-cli` zobrazit všechny akce ve frontě
+- Indexer (nebo jiný software) může akce ve frontě schválit nebo zrušit pomocí příkazu `indexer-cli`. Příkazy approve a cancel přijímají jako vstup pole id akcí.
+- Pracovník provádějící operace pravidelně kontroluje frontu schválených akcí. Vezme z fronty `schválené` akce, pokusí se je provést a aktualizuje hodnoty v db v závislosti na stavu provedení na `úspěšné` nebo `neúspěšné`.
+- Pokud je akce úspěšná, pracovník zajistí, že je přítomno pravidlo indexování, které agentovi říká, jak má alokaci dále spravovat, což je užitečné při provádění ručních akcí, když je agent v režimu `auto` nebo `oversight`.
+- Indexer může sledovat frontu akcí a zobrazit historii jejich provádění a v případě potřeby znovu schválit a aktualizovat položky akcí, pokud se nepodařilo je provést. Fronta akcí poskytuje historii všech akcí zařazených do fronty a provedených.
-Data model:
+Datový model:
```graphql
Type ActionInput {
@@ -659,7 +659,7 @@ ActionType {
}
```
-Example usage from source:
+Příklad použití ze zdroje:
```bash
graph indexer actions get all
@@ -679,34 +679,34 @@ graph indexer actions approve 1 3 5
graph indexer actions execute approve
```
-Note that supported action types for allocation management have different input requirements:
+Všimněte si, že podporované typy akcí pro správu přidělování mají různé vstupní požadavky:
-- `Allocate` - allocate stake to a specific subgraph deployment
+- `Allocate` - přidělí podíl konkrétnímu nasazení podgrafu
- - required action params:
+ - požadované parametry akce:
- deploymentID
- - amount
+ - částka
-- `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
+- `Unallocate` - uzavře alokaci, čímž uvolní podíl k přerozdělení jinam
- - required action params:
+ - požadované parametry akce:
- allocationID
- deploymentID
- - optional action params:
+ - volitelné parametry akce:
- poi
- - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+ - síla (vynutí pomocí poskytnutého POI, i když neodpovídá tomu, co poskytuje uzel graf)
-- `Reallocate` - atomically close allocation and open a fresh allocation for the same subgraph deployment
+- `Přerozdělit` – atomicky uzavřít alokaci a otevřít novou alokaci pro stejné nasazení podgrafu
- - required action params:
+ - požadované parametry akce:
- allocationID
- deploymentID
- - amount
- - optional action params:
+ - částka
+ - volitelné parametry akce:
- poi
- - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
+ - síla (vynutí pomocí poskytnutého POI, i když neodpovídá tomu, co poskytuje uzel graf)
-#### Cost models
+#### Nákladové modely
Cost models provide dynamic pricing for queries based on market and query attributes. The Indexer Service shares a cost model with the gateways for each subgraph for which they intend to respond to queries. The gateways, in turn, use the cost model to make Indexer selection decisions per query and to negotiate payment with chosen Indexers.
diff --git a/website/pages/cs/network/overview.mdx b/website/pages/cs/network/overview.mdx
index bee546908372..6d0e628ec063 100644
--- a/website/pages/cs/network/overview.mdx
+++ b/website/pages/cs/network/overview.mdx
@@ -1,15 +1,15 @@
---
-title: Network Overview
+title: Přehled sítě
---
-The Graph Network is a decentralized indexing protocol for organizing blockchain data. Applications use GraphQL to query open APIs called subgraphs, to retrieve data that is indexed on the network. With The Graph, developers can build serverless applications that run entirely on public infrastructure.
+Sit' Graf je decentralizovaný indexovací protokol pro organizaci dat v blockchainu. Aplikace používají GraphQL k dotazování otevřených API zvaných podgrafy, aby získaly data, která jsou v síti indexována. Díky Graf mohou vývojáři vytvářet bezserverové aplikace, které běží výhradně na veřejné infrastruktuře.
-## Overview
+## Přehled
-The Graph Network consists of Indexers, Curators and Delegators that provide services to the network, and serve data to Web3 applications. Consumers use the applications and consume the data.
+Síť grafů se skládá z indexátorů, kurátorů a delegátorů, kteří poskytují služby síti a obsluhují data aplikací Web3. Spotřebitelé používají aplikace a spotřebovávají data.
-To ensure economic security of The Graph Network and the integrity of data being queried, participants stake and use Graph Tokens ([GRT](/tokenomics)). GRT is a work utility token that is an ERC-20 used to allocate resources in the network.
+Pro zajištění ekonomické bezpečnosti sítě Graf a integrity dotazovaných dat účastníci sázejí a používají graf tokeny ([GRT](/tokenomics)). GRT je pracovní užitkový token, který má hodnotu ERC-20 a slouží k přidělování zdrojů v síti.
-Active Indexers, Curators and Delegators can provide services and earn income from the network, proportional to the amount of work they perform and their GRT stake.
+Aktivní indexátoři, kurátoři a delegáti mohou poskytovat služby a vydělávat na síti úměrně množství práce, kterou vykonají, a svému podílu GRT.
diff --git a/website/pages/cs/new-chain-integration.mdx b/website/pages/cs/new-chain-integration.mdx
index b5492d5061af..d630858a40ad 100644
--- a/website/pages/cs/new-chain-integration.mdx
+++ b/website/pages/cs/new-chain-integration.mdx
@@ -1,39 +1,39 @@
---
-title: Integrating New Networks
+title: Integrace nových sítí
---
-Graph Node can currently index data from the following chain types:
+Uzel grafu může v současné době indexovat data z následujících typů řetězců:
- Ethereum, via EVM JSON-RPC and [Ethereum Firehose](https://github.com/streamingfast/firehose-ethereum)
-- NEAR, via a [NEAR Firehose](https://github.com/streamingfast/near-firehose-indexer)
-- Cosmos, via a [Cosmos Firehose](https://github.com/graphprotocol/firehose-cosmos)
-- Arweave, via an [Arweave Firehose](https://github.com/graphprotocol/firehose-arweave)
+- NEAR, prostřednictvím [NEAR Firehose](https://github.com/streamingfast/near-firehose-indexer)
+- Cosmos, prostřednictvím [Cosmos Firehose](https://github.com/graphprotocol/firehose-cosmos)
+- Arweave, prostřednictvím [Arweave Firehose](https://github.com/graphprotocol/firehose-arweave)
-If you are interested in any of those chains, integration is a matter of Graph Node configuration and testing.
+Pokud máte zájem o některý z těchto řetězců, je integrace otázkou konfigurace a testování uzlu Graf.
-If you are interested in a different chain type, a new with Graph Node must be built. Our recommended approach is developing a new Firehose for the chain in question and then the integration of that Firehose with Graph Node. More info below.
+Pokud máte zájem o jiný typ řetězce, je třeba vytvořit novou integraci s Uzel Graf. Naším doporučeným přístupem je vytvoření nového Firehose pro daný řetězec a následná integrace tohoto Firehose s Uzel Graf. Více informací naleznete níže.
**1. EVM JSON-RPC**
-If the blockchain is EVM equivalent and the client/node exposes the standard EVM JSON-RPC API, Graph Node should be able to index the new chain. For more information, refer to [Testing an EVM JSON-RPC](new-chain-integration#testing-an-evm-json-rpc).
+Pokud je blockchain ekvivalentní EVM a klient/uzel vystavuje standardní EVM JSON-RPC API, měl by být Uzel Grafu schopen indexovat nový řetězec. Další informace naleznete v části [Testování EVM JSON-RPC](new-chain-integration#testing-an-evm-json-rpc).
**2. Firehose**
-For non-EVM-based chains, Graph Node must ingest blockchain data via gRPC and known type definitions. This can be done via [Firehose](firehose/), a new technology developed by [StreamingFast](https://www.streamingfast.io/) that provides a highly-scalable indexing blockchain solution using a files-based and streaming-first approach. Reach out to the [StreamingFast team](mailto:integrations@streamingfast.io/) if you need help with Firehose development.
+U řetězců, které nejsou založeny na EvM, musí Uzel Graf přijímat data blockchainu prostřednictvím gRPC a známých definic typů. To lze provést prostřednictvím [Firehose](firehose/), nové technologie vyvinuté společností [StreamingFast](https://www.streamingfast.io/), která poskytuje vysoce škálovatelné řešení indexování blockchainu pomocí přístupu založeného na souborech a streamování. Pokud potřebujete s vývojem Firehose pomoci, obraťte se na tým [StreamingFast](mailto:integrations@streamingfast.io/).
-## Difference between EVM JSON-RPC & Firehose
+## Rozdíl mezi EVM JSON-RPC a Firehose
-While the two are suitable for subgraphs, a Firehose is always required for developers wanting to build with [Substreams](substreams/), like building [Substreams-powered subgraphs](cookbook/substreams-powered-subgraphs/). In addition, Firehose allows for improved indexing speeds when compared to JSON-RPC.
+Zatímco pro podgrafy jsou tyto dva typy vhodné, pro vývojáře, kteří chtějí vytvářet pomocí [Substreams](substreams/), jako je vytváření [Substreams-powered subgraphs](cookbook/substreams-powered-subgraphs/), je vždy vyžadován Firehose. Firehose navíc umožňuje vyšší rychlost indexování ve srovnání s JSON-RPC.
-New EVM chain integrators may also consider the Firehose-based approach, given the benefits of substreams and its massive parallelized indexing capabilities. Supporting both allows developers to choose between building substreams or subgraphs for the new chain.
+Noví integrátoři řetězců EVM mohou také zvážit přístup založený na technologii Firehose vzhledem k výhodám substreamů a jejím masivním možnostem paralelizovaného indexování. Podpora obojího umožňuje vývojářům zvolit si mezi vytvářením substreamů nebo podgrafů pro nový řetězec.
-> **NOTE**: A Firehose-based integration for EVM chains will still require Indexers to run the chain's archive RPC node to properly index subgraphs. This is due to the Firehose's inability to provide smart contract state typically accessible by the `eth_call` RPC method. (It's worth reminding that eth_calls are [not a good practice for developers](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/))
+> **POZNÁMKA**: Integrace založená na Firehose pro řetězce EVM bude stále vyžadovat, aby indexátory spustily archivační uzel RPC řetězce, aby správně indexovaly podgrafy. Důvodem je neschopnost Firehose poskytovat stav inteligentních kontraktů typicky přístupný metodou `eth_call` RPC. (Stojí za to připomenout, že eth_call je [pro vývojáře není dobrou praxí](https://thegraph.com/blog/improve-subgraph-performance-reduce-eth-calls/))
---
-## Testing an EVM JSON-RPC
+## Testování EVM JSON-RPC
-For Graph Node to be able to ingest data from an EVM chain, the RPC node must expose the following EVM JSON RPC methods:
+Aby mohl uzel Grafu přijímat data z řetězce EVM, musí uzel RPC zpřístupnit následující metody EVM JSON RPC:
- `eth_getLogs`
- `eth_call` \_(for historical blocks, with EIP-1898 - requires archive node):
@@ -41,26 +41,26 @@ For Graph Node to be able to ingest data from an EVM chain, the RPC node must ex
- `eth_getBlockByHash`
- `net_version`
- `eth_getTransactionReceipt`, in a JSON-RPC batch request
-- _`trace_filter`_ _(optionally required for Graph Node to support call handlers)_
+- _`trace_filter`_ _(volitelně vyžadováno pro Uzel Graf, aby podporoval obsluhu volání)_
-### Graph Node Configuration
+### Config uzlu grafu
-**Start by preparing your local environment**
+**Začněte přípravou místního prostředí**
-1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
-2. Modify [this line](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) to include the new network name and the EVM JSON RPC compliant URL
- > Do not change the env var name itself. It must remain `ethereum` even if the network name is different.
-3. Run an IPFS node or use the one used by The Graph: https://api.thegraph.com/ipfs/
+1. [Clone Graph Node](https://github.com/graphprotocol/graph-node)
+2. Upravte [tento řádek](https://github.com/graphprotocol/graph-node/blob/master/docker/docker-compose.yml#L22) tak, aby obsahoval nový název sítě a URL adresu EVM kompatibilní s JSON RPC
+ > Samotný název env var neměňte. Musí zůstat `ethereum`, i když je název sítě jiný.
+3. Spusťte uzel IPFS nebo použijte ten, který používá Graf: https://api.thegraph.com/ipfs/
-**Test the integration by locally deploying a subgraph**
+**Testování integrace lokálním nasazením podgrafu**
-1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
-2. Create a simple example subgraph. Some options are below:
- 1. The pre-packed [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) smart contract and subgraph is a good starting point
- 2. Bootstrap a local subgraph from any existing smart contract or solidity dev environment [using Hardhat with a Graph plugin](https://github.com/graphprotocol/hardhat-graph)
-3. Adapt the resulting `subgraph.yaml` by changing [`dataSources.network`](http://dataSources.network) to the same name previously passed on to Graph Node.
-4. Create your subgraph in Graph Node: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
-5. Publish your subgraph to Graph Node: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
+1. Install [graph-cli](https://github.com/graphprotocol/graph-cli)
+2. Vytvořte jednoduchý příklad podgrafu. Některé možnosti jsou uvedeny níže:
+ 1. Předpřipravený chytrá smlouva [Gravitar](https://github.com/graphprotocol/example-subgraph/tree/f89bdd4628efa4badae7367d4919b3f648083323) a podgraf je dobrým výchozím bodem
+ 2. Zavedení lokálního podgrafu z jakéhokoli existujícího chytrého kontraktu nebo vývojového prostředí Solidity [pomocí Hardhat s plugin Graph](https://github.com/graphprotocol/hardhat-graph)
+3. Upravte výsledný soubor `subgraph.yaml` změnou názvu [`dataSources.network`](http://dataSources.network) na stejný název, který byl dříve předán z Uzel Graf.
+4. Vytvořte podgraf v uzlu Graf: `graph create $SUBGRAPH_NAME --node $GRAPH_NODE_ENDPOINT`
+5. Zveřejněte svůj podgraf v uzlu Graf: `graph deploy $SUBGRAPH_NAME --ipfs $IPFS_ENDPOINT --node $GRAPH_NODE_ENDPOINT`
Graph Node should be syncing the deployed subgraph if there are no errors. Give it time to sync, then send some GraphQL queries to the API endpoint printed in the logs.
@@ -70,6 +70,6 @@ Graph Node should be syncing the deployed subgraph if there are no errors. Give
Integrating a new chain is also possible using the Firehose approach. This is currently the best option for non-EVM chains and a requirement for substreams support. Additional documentation focuses on how Firehose works, adding Firehose support for a new chain and integrating it with Graph Node. Recommended docs for integrators:
-1. [General docs on Firehose](firehose/)
-2. [Adding Firehose support for a new chain](https://firehose.streamingfast.io/integrate-new-chains/integration-overview)
-3. [Integrating Graph Node with a new chain via Firehose](https://github.com/graphprotocol/graph-node/blob/master/docs/implementation/add-chain.md)
+1. [General docs on Firehose](firehose/)
+2. [Adding Firehose support for a new chain](https://firehose.streamingfast.io/integrate-new-chains/integration-overview)
+3. [Integrating Graph Node with a new chain via Firehose](https://github.com/graphprotocol/graph-node/blob/master/docs/implementation/add-chain.md)
diff --git a/website/pages/cs/operating-graph-node.mdx b/website/pages/cs/operating-graph-node.mdx
index 4f0f856db111..6b1190311ea1 100644
--- a/website/pages/cs/operating-graph-node.mdx
+++ b/website/pages/cs/operating-graph-node.mdx
@@ -1,40 +1,40 @@
---
-title: Operating Graph Node
+title: Uzel provozního graf
---
-Graph Node is the component which indexes subgraphs, and makes the resulting data available to query via a GraphQL API. As such it is central to the indexer stack, and correct operation of Graph Node is crucial to running a successful indexer.
+Graf Uzel je komponenta, která indexuje podgrafy a zpřístupňuje výsledná data k dotazování prostřednictvím rozhraní GraphQL API. Jako taková je ústředním prvkem zásobníku indexeru a její správná činnost je pro úspěšný provoz indexeru klíčová.
-This provides a contextual overview of Graph Node, and some of the more advanced options available to indexers. Detailed documentation and instructions can be found in the [Graph Node repository](https://github.com/graphprotocol/graph-node).
+Tato část poskytuje kontextový přehled o uzlu Graf a o některých pokročilejších možnostech, které jsou indexátorům k dispozici. Podrobnou dokumentaci a pokyny najdete v úložišti [Graf Uzel](https://github.com/graphprotocol/graph-node).
-## Graph Node
+## Uzel grafu
-[Graph Node](https://github.com/graphprotocol/graph-node) is the reference implementation for indexing Subgraphs on The Graph Network, connecting to blockchain clients, indexing subgraphs and making indexed data available to query.
+[Graf Uzel](https://github.com/graphprotocol/graph-node) je referenční implementace pro indexování podgrafů v síti Graf, připojení ke klientům blockchainu, indexování podgrafů a zpřístupnění indexovaných dat k dotazování.
-Graph Node (and the whole indexer stack) can be run on bare metal, or in a cloud environment. This flexibility of the central indexing component is crucial to the robustness of The Graph Protocol. Similarly, Graph Node can be [built from source](https://github.com/graphprotocol/graph-node), or indexers can use one of the [provided Docker Images](https://hub.docker.com/r/graphprotocol/graph-node).
+Graf Uzel (a celý indexer stack) lze provozovat na holém železe nebo v cloudovém prostředí. Tato flexibilita centrální indexovací komponenty je klíčová pro robustnost protokolu v Graf Protocol. Stejně tak může být Graf Uzel [postaven ze zdrojového kódu](https://github.com/graphprotocol/graph-node), nebo mohou indexátory používat jeden z [poskytovaných obrazů Docker](https://hub.docker.com/r/graphprotocol/graph-node).
-### PostgreSQL database
+### Databáze PostgreSQL
-The main store for the Graph Node, this is where subgraph data is stored, as well as metadata about subgraphs, and subgraph-agnostic network data such as the block cache, and eth_call cache.
+Hlavní úložiště pro uzel Graf Uzel, kde jsou uložena data podgrafů, metadata o podgraf a síťová data týkající se podgrafů, jako je bloková cache a cache eth_call.
-### Network clients
+### Síťoví klienti
-In order to index a network, Graph Node needs access to a network client via an EVM-compatible JSON-RPC API. This RPC may connect to a single client or it could be a more complex setup that load balances across multiple.
+Aby mohl uzel Graph Node indexovat síť, potřebuje přístup k síťovému klientovi prostřednictvím rozhraní API JSON-RPC kompatibilního s EVM. Toto RPC se může připojit k jedinému klientovi nebo může jít o složitější nastavení, které vyrovnává zátěž mezi více klienty.
-While some subgraphs may just require a full node, some may have indexing features which require additional RPC functionality. Specifically subgraphs which make `eth_calls` as part of indexing will require an archive node which supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), and subgraphs with `callHandlers`, or `blockHandlers` with a `call` filter, require `trace_filter` support ([see trace module documentation here](https://openethereum.github.io/JSONRPC-trace-module)).
+Zatímco některé podgrafy mohou vyžadovat pouze plný uzel, některé mohou mít indexovací funkce, které vyžadují další funkce RPC. Konkrétně podgrafy, které v rámci indexování provádějí `eth_calls`, budou vyžadovat archivní uzel, který podporuje [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898), a podgrafy s `callHandlers` nebo `blockHandlers` s filtrem `call` vyžadují podporu `trace_filter` ([viz dokumentace modulu trace zde](https://openethereum.github.io/JSONRPC-trace-module)).
-**Network Firehoses** - a Firehose is a gRPC service providing an ordered, yet fork-aware, stream of blocks, developed by The Graph's core developers to better support performant indexing at scale. This is not currently an Indexer requirement, but Indexers are encouraged to familiarise themselves with the technology, ahead of full network support. Learn more about the Firehose [here](https://firehose.streamingfast.io/).
+**Network Firehoses** - Firehose je služba gRPC poskytující uspořádaný, ale vidlicově orientovaný proud bloků, vyvinutá hlavními vývojáři Grafu pro lepší podporu výkonného indexování v měřítku. V současné době to není požadavek na indexátor, ale doporučujeme indexátorům, aby se s touto technologií seznámili ještě před plnou podporou sítě. Více informací o Firehose [zde](https://firehose.streamingfast.io/).
-### IPFS Nodes
+### IPFS uzly
-Subgraph deployment metadata is stored on the IPFS network. The Graph Node primarily accesses the IPFS node during subgraph deployment to fetch the subgraph manifest and all linked files. Network indexers do not need to host their own IPFS node. An IPFS node for the network is hosted at https://ipfs.network.thegraph.com.
+Metadata nasazení podgrafů jsou uložena v síti IPFS. Uzel Graf přistupuje během nasazení podgrafu především k uzlu IPFS, aby načetl manifest podgrafu a všechny propojené soubory. Síťové indexery nemusí hostit vlastní uzel IPFS. Uzel IPFS pro síť je hostován na adrese https://ipfs.network.thegraph.com.
-### Prometheus metrics server
+### Metrický server Prometheus
-To enable monitoring and reporting, Graph Node can optionally log metrics to a Prometheus metrics server.
+Aby bylo možné monitorovat a podávat zprávy, může uzel Graf volitelně zaznamenávat metriky na metrický server Prometheus.
-### Getting started from source
+### Začínáme od zdroje
-#### Install prerequisites
+#### Instalace předpokladů
- **Rust**
@@ -42,15 +42,15 @@ To enable monitoring and reporting, Graph Node can optionally log metrics to a P
- **IPFS**
-- **Additional Requirements for Ubuntu users** - To run a Graph Node on Ubuntu a few additional packages may be needed.
+- **Další požadavky pro uživatele Ubuntu** - Pro spuštění Uzel Graf v Ubuntu může být potřeba několik dalších balíčků.
```sh
sudo apt-get install -y clang libpg-dev libssl-dev pkg-config
```
-#### Setup
+#### Nastavení
-1. Start a PostgreSQL database server
+1. Spuštění databázového serveru PostgreSQL
```sh
initdb -D .postgres
@@ -58,9 +58,9 @@ pg_ctl -D .postgres -l logfile start
createdb graph-node
```
-2. Clone [Graph Node](https://github.com/graphprotocol/graph-node) repo and build the source by running `cargo build`
+2. Klonujte repozitář [Uzel Graf](https://github.com/graphprotocol/graph-node) a sestavte zdrojový kód spuštěním příkazu `cargo build`
-3. Now that all the dependencies are setup, start the Graph Node:
+3. Nyní, když jsou všechny závislosti nastaveny, spusťte uzel Graf:
```sh
cargo run -p graph-node --release -- \
@@ -69,37 +69,37 @@ cargo run -p graph-node --release -- \
--ipfs https://ipfs.network.thegraph.com
```
-### Getting started with Kubernetes
+### Začínáme s Kubernetes
-A complete Kubernetes example configuration can be found in the [indexer repository](https://github.com/graphprotocol/indexer/tree/main/k8s).
+Kompletní příklad konfigurace Kubernetes naleznete v úložišti [indexer](https://github.com/graphprotocol/indexer/tree/main/k8s).
### Ports
-When it is running Graph Node exposes the following ports:
+Když je Graf Uzel spuštěn, zpřístupňuje následující ports:
-| Port | Purpose | Routes | CLI Argument | Environment Variable |
+| Port | Účel | Trasy | CLI Argument | Proměnná prostředí |
| --- | --- | --- | --- | --- |
-| 8000 | GraphQL HTTP server
(for subgraph queries) | /subgraphs/id/...
/subgraphs/name/.../... | --http-port | - |
-| 8001 | GraphQL WS
(for subgraph subscriptions) | /subgraphs/id/...
/subgraphs/name/.../... | --ws-port | - |
-| 8020 | JSON-RPC
(for managing deployments) | / | --admin-port | - |
-| 8030 | Subgraph indexing status API | /graphql | --index-node-port | - |
-| 8040 | Prometheus metrics | /metrics | --metrics-port | - |
+| 8000 | GraphQL HTTP server
(pro dotazy podgrafy) | /subgraphs/id/...
/subgraphs/name/.../... | --http-port | - |
+| 8001 | GraphQL WS
(pro odběry podgrafů) | /subgraphs/id/...
/subgraphs/name/.../... | --ws-port | - |
+| 8020 | JSON-RPC
(pro správu nasazení) | / | --admin-port | - |
+| 8030 | Stav indexování podgrafů API | /graphql | --index-node-port | - |
+| 8040 | Metriky Prometheus | /metrics | --metrics-port | - |
-> **Important**: Be careful about exposing ports publicly - **administration ports** should be kept locked down. This includes the the Graph Node JSON-RPC endpoint.
+> **Důležité**: Dávejte pozor na veřejné vystavování portů - **administrační porty** by měly být uzamčeny. To se týká i koncového bodu JSON-RPC uzlu Graf.
-## Advanced Graph Node configuration
+## Pokročilá konfigurace uzlu Graf
-At its simplest, Graph Node can be operated with a single instance of Graph Node, a single PostgreSQL database, an IPFS node, and the network clients as required by the subgraphs to be indexed.
+V nejjednodušším případě lze Graf Uzel provozovat s jednou instancí Graf Uzel, jednou databází PostgreSQL, uzlem IPFS a síťovými klienty podle potřeby indexovaných podgrafů.
-This setup can be scaled horizontally, by adding multiple Graph Nodes, and multiple databases to support those Graph Nodes. Advanced users may want to take advantage of some of the horizontal scaling capabilities of Graph Node, as well as some of the more advanced configuration options, via the `config.toml` file and Graph Node's environment variables.
+Toto nastavení lze horizontálně škálovat přidáním více graf uzlů a více databází pro podporu těchto graf uzlů. Pokročilí uživatelé mohou chtít využít některé možnosti horizontálního škálování Graf Uzel a také některé pokročilejší možnosti konfigurace prostřednictvím souboru `config.toml` a proměnných prostředí Graph Node.
### `config.toml`
-A [TOML](https://toml.io/en/) configuration file can be used to set more complex configurations than those exposed in the CLI. The location of the file is passed with the --config command line switch.
+Konfigurační soubor [TOML](https://toml.io/en/) lze použít k nastavení složitějších konfigurací, než jaké jsou dostupné v CLI. Umístění souboru se předává pomocí přepínače příkazového řádku --config.
-> When using a configuration file, it is not possible to use the options --postgres-url, --postgres-secondary-hosts, and --postgres-host-weights.
+> Při použití konfiguračního souboru není možné použít volby --postgres-url, --postgres-secondary-hosts a --postgres-host-weights.
-A minimal `config.toml` file can be provided; the following file is equivalent to using the --postgres-url command line option:
+Lze zadat minimální soubor `config.toml`; následující soubor je ekvivalentní použití volby příkazového řádku --postgres-url:
```toml
[store]
@@ -110,19 +110,19 @@ connection="<.. postgres-url argument ..>"
indexers = [ "<.. list of all indexing nodes ..>" ]
```
-Full documentation of `config.toml` can be found in the [Graph Node docs](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
+Úplnou dokumentaci `config.toml` lze nalézt v [dokumentech Graf Uzel](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md).
-#### Multiple Graph Nodes
+#### Více uzlů graf
-Graph Node indexing can scale horizontally, running multiple instances of Graph Node to split indexing and querying across different nodes. This can be done simply by running Graph Nodes configured with a different `node_id` on startup (e.g. in the Docker Compose file), which can then be used in the `config.toml` file to specify [dedicated query nodes](#dedicated-query-nodes), [block ingestors](#dedicated-block-ingestor), and splitting subgraphs across nodes with [deployment rules](#deployment-rules).
+Indexování Graf Uzel lze horizontálně škálovat, přičemž lze spustit více instancí Graf Uzel a rozdělit indexování a dotazování mezi různé uzly. To lze provést jednoduše spuštěním uzlu Graf nakonfigurovaného s jiným `id uzlu` při spuštění (např. v souboru Docker Compose), který lze poté použít v souboru `config.toml` k určení [dedikovaných uzlů pro dotazování](#dedicated-query-nodes), [blokových ingestorů](#dedicated-block-ingestor) a rozdělení podgrafů mezi uzly pomocí [pravidel nasazení](#deployment-rules).
-> Note that multiple Graph Nodes can all be configured to use the same database, which itself can be horizontally scaled via sharding.
+> Všimněte si, že více graf uzlů lze nakonfigurovat tak, aby používaly stejnou databázi, kterou lze horizontálně škálovat pomocí sharding.
-#### Deployment rules
+#### Pravidla nasazení
-Given multiple Graph Nodes, it is necessary to manage deployment of new subgraphs so that the same subgraph isn't being indexed by two different nodes, which would lead to collisions. This can be done by using deployment rules, which can also specify which `shard` a subgraph's data should be stored in, if database sharding is being used. Deployment rules can match on the subgraph name and the network that the deployment is indexing in order to make a decision.
+Při více uzlech graf je nutné řídit nasazení nových podgrafů tak, aby stejný podgraf nebyl indexován dvěma různými uzly, což by vedlo ke kolizím. To lze provést pomocí pravidel nasazení, která mohou také určit, do kterého `shardu` mají být data podgrafu uložena, pokud se používá rozdělení databáze. Pravidla nasazení mohou odpovídat názvu podgrafu a síti, kterou nasazení indexuje, aby bylo možné učinit rozhodnutí.
-Example deployment rule configuration:
+Příklad konfigurace pravidla nasazení:
```toml
[deployment]
@@ -150,51 +150,51 @@ indexers = [
]
```
-Read more about deployment rules [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
+Více informací o pravidlech nasazení [zde](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#controlling-deployment).
-#### Dedicated query nodes
+#### Vyhrazené dotazovací uzly
-Nodes can be configured to explicitly be query nodes by including the following in the configuration file:
+Uzly lze nakonfigurovat tak, aby byly explicitně dotazovacími uzly, a to tak, že do konfiguračního souboru vložíte následující údaje:
```toml
[general]
query = ""
```
-Any node whose --node-id matches the regular expression will be set up to only respond to queries.
+Každý uzel, jehož --node-id odpovídá regulárnímu výrazu, bude nastaven tak, aby odpovídal pouze na dotazy.
-#### Database scaling via sharding
+#### Škálování databáze pomocí sharding
-For most use cases, a single Postgres database is sufficient to support a graph-node instance. When a graph-node instance outgrows a single Postgres database, it is possible to split the storage of graph-node's data across multiple Postgres databases. All databases together form the store of the graph-node instance. Each individual database is called a shard.
+Pro většinu případů použití postačuje k podpoře instance graf uzlu jedna databáze Postgres. Pokud instance graf uzlu přeroste rámec jedné databáze Postgres, je možné rozdělit ukládání dat grafového uzlu do více databází Postgres. Všechny databáze dohromady tvoří úložiště instance graf uzlu. Každá jednotlivá databáze se nazývá shard.
-Shards can be used to split subgraph deployments across multiple databases, and can also be used to use replicas to spread query load across databases. This includes configuring the number of available database connections each `graph-node` should keep in its connection pool for each database, which becomes increasingly important as more subgraphs are being indexed.
+Střepy lze použít k rozdělení nasazení dílčích graf do více databází a lze je také použít k použití replik k rozložení zátěže dotazů mezi databázemi. To zahrnuje konfiguraci počtu dostupných databázových připojení, které by měl každý `graf-node` udržovat ve svém fondu připojení pro každou databázi, což je stále důležitější, když se indexuje více podgrafů.
-Sharding becomes useful when your existing database can't keep up with the load that Graph Node puts on it, and when it's not possible to increase the database size anymore.
+Sharding se stává užitečným, když vaše stávající databáze nedokáže udržet krok se zátěží, kterou na ni Graf Uzel vyvíjí, a když už není možné zvětšit velikost databáze.
-> It is generally better make a single database as big as possible, before starting with shards. One exception is where query traffic is split very unevenly between subgraphs; in those situations it can help dramatically if the high-volume subgraphs are kept in one shard and everything else in another because that setup makes it more likely that the data for the high-volume subgraphs stays in the db-internal cache and doesn't get replaced by data that's not needed as much from low-volume subgraphs.
+> Obecně je lepší vytvořit jednu co největší databázi, než začít s oddíly. Jednou z výjimek jsou případy, kdy je provoz dotazů rozdělen velmi nerovnoměrně mezi dílčí podgrafy; v těchto situacích může výrazně pomoci, pokud jsou dílčí podgrafy s velkým objemem uchovávány v jednom shardu a vše ostatní v jiném, protože toto nastavení zvyšuje pravděpodobnost, že data pro dílčí podgrafu s velkým objemem zůstanou v interní cache db a nebudou nahrazena daty, která nejsou tolik potřebná z dílčích podgrafů s malým objemem.
-In terms of configuring connections, start with max_connections in postgresql.conf set to 400 (or maybe even 200) and look at the store_connection_wait_time_ms and store_connection_checkout_count Prometheus metrics. Noticeable wait times (anything above 5ms) is an indication that there are too few connections available; high wait times there will also be caused by the database being very busy (like high CPU load). However if the database seems otherwise stable, high wait times indicate a need to increase the number of connections. In the configuration, how many connections each graph-node instance can use is an upper limit, and Graph Node will not keep connections open if it doesn't need them.
+Pokud jde o konfiguraci připojení, začněte s max_connections v souboru postgresql.conf nastaveným na 400 (nebo možná dokonce 200) a podívejte se na metriky store_connection_wait_time_ms a store_connection_checkout_count Prometheus. Výrazné čekací doby (cokoli nad 5 ms) jsou známkou toho, že je k dispozici příliš málo připojení; vysoké čekací doby tam budou také způsobeny tím, že databáze je velmi vytížená (například vysoké zatížení procesoru). Pokud se však databáze jinak jeví jako stabilní, vysoké čekací doby naznačují potřebu zvýšit počet připojení. V konfiguraci je horní hranicí, kolik připojení může každá instance graf uzlu používat, a graf uzel nebude udržovat otevřená připojení, pokud je nepotřebuje.
-Read more about store configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
+Více informací o konfiguraci obchodu [zde](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-multiple-databases).
-#### Dedicated block ingestion
+#### Vyhrazené zpracování bloků
-If there are multiple nodes configured, it will be necessary to specify one node which is responsible for ingestion of new blocks, so that all configured index nodes aren't polling the chain head. This is done as part of the `chains` namespace, specifying the `node_id` to be used for block ingestion:
+Pokud je nakonfigurováno více uzlů, je nutné určit jeden uzel, který je zodpovědný za přijímání nových bloků, aby všechny nakonfigurované indexové uzly neprováděly dotazování hlavy řetězce. To se provádí v rámci jmenného prostoru `chains`, kde se zadává `id_uzlu`, který se má používat pro přijímání bloků:
```toml
[chains]
ingestor = "block_ingestor_node"
```
-#### Supporting multiple networks
+#### Podpora více sítí
-The Graph Protocol is increasing the number of networks supported for indexing rewards, and there exist many subgraphs indexing unsupported networks which an indexer would like to process. The `config.toml` file allows for expressive and flexible configuration of:
+Graf protokol zvyšuje počet sítí podporovaných pro indexaci odměn a existuje mnoho podgrafů indexujících nepodporované sítě, které by indexátor rád zpracoval. Soubor `config.toml` umožňuje expresivní a flexibilní konfiguraci:
-- Multiple networks
-- Multiple providers per network (this can allow splitting of load across providers, and can also allow for configuration of full nodes as well as archive nodes, with Graph Node preferring cheaper providers if a given workload allows).
-- Additional provider details, such as features, authentication and the type of provider (for experimental Firehose support)
+- Více sítí
+- Více poskytovatelů na síť (to může umožnit rozdělení zátěže mezi poskytovatele a také konfiguraci plných uzlů i archivních uzlů, přičemž Graph Node může preferovat levnější poskytovatele, pokud to daná pracovní zátěž umožňuje).
+- Další údaje o poskytovateli, jako jsou funkce, ověřování a typ poskytovatele (pro experimentální podporu Firehose)
-The `[chains]` section controls the ethereum providers that graph-node connects to, and where blocks and other metadata for each chain are stored. The following example configures two chains, mainnet and kovan, where blocks for mainnet are stored in the vip shard and blocks for kovan are stored in the primary shard. The mainnet chain can use two different providers, whereas kovan only has one provider.
+Sekce `[chains]` řídí, ke kterým poskytovatelům ethereum se graf uzel připojuje a kde jsou uloženy bloky a další metadata pro jednotlivé řetězce. Následující příklad konfiguruje dva řetězce, mainnet a kovan, přičemž bloky pro mainnet jsou uloženy ve shard vip a bloky pro kovan jsou uloženy v primárním shard. Řetězec mainnet může používat dva různé poskytovatele, zatímco kovan má pouze jednoho poskytovatele.
```toml
[chains]
@@ -210,109 +210,109 @@ shard = "primary"
provider = [ { label = "kovan", url = "http://..", features = [] } ]
```
-Read more about provider configuration [here](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
+Více informací o konfiguraci poskytovatele [zde](https://github.com/graphprotocol/graph-node/blob/master/docs/config.md#configuring-ethereum-providers).
-### Environment variables
+### Proměnná prostředí
-Graph Node supports a range of environment variables which can enable features, or change Graph Node behaviour. These are documented [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
+Graf Uzel podporuje řadu proměnných prostředí, které mohou povolit funkce nebo změnit chování Graf Uzel. Jsou zdokumentovány [zde](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md).
-### Continuous deployment
+### Průběžné nasazování
-Users who are operating a scaled indexing setup with advanced configuration may benefit from managing their Graph Nodes with Kubernetes.
+Uživatelé, kteří provozují škálované nastavení indexování s pokročilou konfigurací, mohou využít správu svých graf uzlů pomocí Kubernetes.
-- The indexer repository has an [example Kubernetes reference](https://github.com/graphprotocol/indexer/tree/main/k8s)
-- [Launchpad](https://docs.graphops.xyz/launchpad/intro) is a toolkit for running a Graph Protocol Indexer on Kubernetes maintained by GraphOps. It provides a set of Helm charts and a CLI to manage a Graph Node deployment.
+- V úložišti indexeru je [příklad odkazu Kubernetes](https://github.com/graphprotocol/indexer/tree/main/k8s)
+- [Launchpad](https://docs.graphops.xyz/launchpad/intro) je sada nástrojů pro provozování Graf Protocol Indexeru v Kubernetes, kterou spravuje společnost GraphOps. Poskytuje sadu grafů Helm a CLI pro správu nasazení uzlu Graf.
-### Managing Graph Node
+### Správa uzlu graf
-Given a running Graph Node (or Graph Nodes!), the challenge is then to manage deployed subgraphs across those nodes. Graph Node surfaces a range of tools to help with managing subgraphs.
+Vzhledem k běžícímu uzlu Graf (nebo uzlům Graf Uzel!) je pak úkolem spravovat rozmístěné podgrafy v těchto uzlech. Graf Uzel nabízí řadu nástrojů, které pomáhají se správou podgrafů.
-#### Logging
+#### Protokolování
-Graph Node's logs can provide useful information for debugging and optimisation of Graph Node and specific subgraphs. Graph Node supports different log levels via the `GRAPH_LOG` environment variable, with the following levels: error, warn, info, debug or trace.
+Protokoly Graf Uzel mohou poskytnout užitečné informace pro ladění a optimalizaci Graf Uzel a konkrétních podgrafů. Graf Uzel podporuje různé úrovně protokolů prostřednictvím proměnné prostředí `GRAPH_LOG` s následujícími úrovněmi: error, warn, info, debug nebo trace.
-In addition setting `GRAPH_LOG_QUERY_TIMING` to `gql` provides more details about how GraphQL queries are running (though this will generate a large volume of logs).
+Kromě toho nastavení `GRAPH_LOG_QUERY_TIMING` na `gql` poskytuje více podrobností o tom, jak dotazy GraphQL probíhají (i když to bude generovat velký objem protokolů).
-#### Monitoring & alerting
+#### Monitorování & upozornění
-Graph Node provides the metrics via Prometheus endpoint on 8040 port by default. Grafana can then be used to visualise these metrics.
+Graf Uzel poskytuje metriky prostřednictvím koncového bodu Prometheus na portu 8040 ve výchozím nastavení. K vizualizaci těchto metrik lze pak použít nástroj Grafana.
-The indexer repository provides an [example Grafana configuration](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
+Úložiště indexeru poskytuje [příklad konfigurace Grafana](https://github.com/graphprotocol/indexer/blob/main/k8s/base/grafana.yaml).
#### Graphman
-`graphman` is a maintenance tool for Graph Node, helping with diagnosis and resolution of different day-to-day and exceptional tasks.
+`graphman` je nástroj pro údržbu Graf Uzel, který pomáhá s diagnostikou a řešením různých každodenních i výjimečných úloh.
-The graphman command is included in the official containers, and you can docker exec into your graph-node container to run it. It requires a `config.toml` file.
+Příkaz graphman je součástí oficiálních kontejnerů a můžete jej spustit pomocí docker exec do kontejneru graph-node. Vyžaduje soubor `config.toml`.
-Full documentation of `graphman` commands is available in the Graph Node repository. See \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) in the Graph Node `/docs`
+Úplná dokumentace příkazů `graphman` je k dispozici v úložišti Graf Uzel. Viz \[/docs/graphman.md\] (https://github.com/graphprotocol/graph-node/blob/master/docs/graphman.md) v Graf Uzel `/docs`
-### Working with subgraphs
+### Práce s podgrafy
-#### Indexing status API
+#### Stav indexování API
-Available on port 8030/graphql by default, the indexing status API exposes a range of methods for checking indexing status for different subgraphs, checking proofs of indexing, inspecting subgraph features and more.
+API pro stav indexování, které je ve výchozím nastavení dostupné na portu 8030/graphql, nabízí řadu metod pro kontrolu stavu indexování pro různé podgrafy, kontrolu důkazů indexování, kontrolu vlastností podgrafů a další.
-The full schema is available [here](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
+Úplné schéma je k dispozici [zde](https://github.com/graphprotocol/graph-node/blob/master/server/index-node/src/schema.graphql).
-#### Indexing performance
+#### Výkonnost indexování
-There are three separate parts of the indexing process:
+Proces indexování má tři samostatné části:
-- Fetching events of interest from the provider
-- Processing events in order with the appropriate handlers (this can involve calling the chain for state, and fetching data from the store)
-- Writing the resulting data to the store
+- Získávání zajímavých událostí od zprostředkovatele
+- Zpracování událostí v pořadí pomocí příslušných obslužných (to může zahrnovat volání řetězce pro zjištění stavu a načtení dat z úložiště)
+- Zápis výsledných dat do úložiště
-These stages are pipelined (i.e. they can be executed in parallel), but they are dependent on one another. Where subgraphs are slow to index, the underlying cause will depend on the specific subgraph.
+Tyto fáze jsou spojeny do potrubí (tj. mohou být prováděny paralelně), ale jsou na sobě závislé. Pokud se podgrafy indexují pomalu, bude příčina záviset na konkrétním podgrafu.
-Common causes of indexing slowness:
+Běžné příčiny pomalého indexování:
-- Time taken to find relevant events from the chain (call handlers in particular can be slow, given the reliance on `trace_filter`)
-- Making large numbers of `eth_calls` as part of handlers
-- A large amount of store interaction during execution
-- A large amount of data to save to the store
-- A large number of events to process
-- Slow database connection time, for crowded nodes
-- The provider itself falling behind the chain head
-- Slowness in fetching new receipts at the chain head from the provider
+- Čas potřebný k nalezení relevantních událostí z řetězce (zejména obsluhy volání mohou být pomalé vzhledem k závislosti na `trace_filter`)
+- Vytváření velkého počtu `eth_calls` jako součást obslužných
+- Velké množství interakcí s úložištěm během provádění
+- Velké množství dat k uložení do úložiště
+- Velký počet událostí ke zpracování
+- Pomalá doba připojení k databázi u přeplněných uzlů
+- Samotný poskytovatel se dostává za hlavu řetězu
+- Pomalé načítání nových účtenek od poskytovatele v hlavě řetězce
-Subgraph indexing metrics can help diagnose the root cause of indexing slowness. In some cases, the problem lies with the subgraph itself, but in others, improved network providers, reduced database contention and other configuration improvements can markedly improve indexing performance.
+Metriky indexování podgrafů mohou pomoci diagnostikovat hlavní příčinu pomalého indexování. V některých případech spočívá problém v samotném podgrafu, ale v jiných případech mohou zlepšení síťových poskytovatelů, snížení konfliktů v databázi a další zlepšení konfigurace výrazně zlepšit výkon indexování.
-#### Failed subgraphs
+#### Neúspěšné podgrafy
-During indexing subgraphs might fail, if they encounter data that is unexpected, some component not working as expected, or if there is some bug in the event handlers or configuration. There are two general types of failure:
+Během indexování mohou dílčí graf selhat, pokud narazí na neočekávaná data, pokud některá komponenta nefunguje podle očekávání nebo pokud je chyba ve zpracovatelích událostí nebo v konfiguraci. Existují dva obecné typy selhání:
-- Deterministic failures: these are failures which will not be resolved with retries
-- Non-deterministic failures: these might be down to issues with the provider, or some unexpected Graph Node error. When a non-deterministic failure occurs, Graph Node will retry the failing handlers, backing off over time.
+- Deterministická selhání: jedná se o selhání, která nebudou vyřešena opakovanými pokusy
+- Nedeterministická selhání: mohou být způsobena problémy se zprostředkovatelem nebo neočekávanou chybou grafického uzlu. Pokud dojde k nedeterministickému selhání, uzel Graf zopakuje selhání obsluhy a postupně se vrátí zpět.
-In some cases a failure might be resolvable by the indexer (for example if the error is a result of not having the right kind of provider, adding the required provider will allow indexing to continue). However in others, a change in the subgraph code is required.
+V některých případech může být chyba řešitelná indexátorem (například pokud je chyba důsledkem toho, že není k dispozici správný typ zprostředkovatele, přidání požadovaného zprostředkovatele umožní pokračovat v indexování). V jiných případech je však nutná změna v kódu podgrafu.
-> Deterministic failures are considered "final", with a Proof of Indexing generated for the failing block, while non-determinstic failures are not, as the subgraph may manage to "unfail" and continue indexing. In some cases, the non-deterministic label is incorrect, and the subgraph will never overcome the error; such failures should be reported as issues on the Graph Node repository.
+> Deterministická selhání jsou považována za "konečná" a pro selhávající blok je vygenerován důkaz indexace, zatímco nedeterministická selhání nikoli, protože podgraf může selhat a pokračovat v indexaci. V některých případech je nedeterministické označení nesprávné a podgraf chybu nikdy nepřekoná; taková selhání by měla být hlášena jako problémy v úložišti Uzel Graf.
-#### Block and call cache
+#### Bloková a volací mezipaměť
-Graph Node caches certain data in the store in order to save refetching from the provider. Blocks are cached, as are the results of `eth_calls` (the latter being cached as of a specific block). This caching can dramatically increase indexing speed during "resyncing" of a slightly altered subgraph.
+Uzel Graf ukládá určitá data do mezipaměti v úložišti, aby se ušetřilo opětovné načítání od zprostředkovatele. Bloky jsou ukládány do mezipaměti, stejně jako výsledky `eth_calls` (ty jsou ukládány do mezipaměti jako konkrétní blok). Toto ukládání do mezipaměti může výrazně zvýšit rychlost indexování při "resynchronizaci" mírně pozměněného podgrafu.
-However, in some instances, if an Ethereum node has provided incorrect data for some period, that can make its way into the cache, leading to incorrect data or failed subgraphs. In this case indexers can use `graphman` to clear the poisoned cache, and then rewind the affected subgraphs, which will then fetch fresh data from the (hopefully) healthy provider.
+Pokud však uzel Etherea po určitou dobu poskytoval nesprávná data, mohou se v některých případech dostat do mezipaměti, což může vést k nesprávným datům nebo neúspěšným podgrafům. V takovém případě mohou indexery použít `graphman` k vymazání otrávené cache a následnému přetočení postižených podgrafů, které pak načtou čerstvá data od (doufejme) zdravého poskytovatele.
-If a block cache inconsistency is suspected, such as a tx receipt missing event:
+Pokud existuje podezření na nekonzistenci blokové mezipaměti, například chybějící událost tx receipt:
-1. `graphman chain list` to find the chain name.
-2. `graphman chain check-blocks by-number ` will check if the cached block matches the provider, and deletes the block from the cache if it doesn’t.
- 1. If there is a difference, it may be safer to truncate the whole cache with `graphman chain truncate `.
- 2. If the block matches the provider, then the issue can be debugged directly against the provider.
+1. `graphman chain list` pro zjištění názvu řetězce.
+2. `graphman chain check-blocks by-number ` zkontroluje, zda blok uložený v mezipaměti odpovídá poskytovateli, a pokud ne, odstraní blok z mezipaměti.
+ 1. Pokud existuje rozdíl, může být bezpečnější zkrátit celou mezipaměť pomocí `graphman chain truncate `.
+ 2. Pokud se blok shoduje s poskytovatelem, lze problém ladit přímo proti poskytovateli.
-#### Querying issues and errors
+#### Problémy a chyby při dotazování
-Once a subgraph has been indexed, indexers can expect to serve queries via the subgraph's dedicated query endpoint. If the indexer is hoping to serve significant query volume, a dedicated query node is recommended, and in case of very high query volumes, indexers may want to configure replica shards so that queries don't impact the indexing process.
+Jakmile je podgraf indexován, lze očekávat, že indexery budou obsluhovat dotazy prostřednictvím koncového bodu vyhrazeného pro dotazy podgrafu. Pokud indexátor doufá, že bude obsluhovat značný objem dotazů, doporučuje se použít vyhrazený uzel pro dotazy a v případě velmi vysokého objemu dotazů mohou indexátory chtít nakonfigurovat oddíly replik tak, aby dotazy neovlivňovaly proces indexování.
-However, even with a dedicated query node and replicas, certain queries can take a long time to execute, and in some cases increase memory usage and negatively impact the query time for other users.
+I s vyhrazeným dotazovacím uzlem a replikami však může provádění některých dotazů trvat dlouho a v některých případech může zvýšit využití paměti a negativně ovlivnit dobu dotazování ostatních uživatelů.
-There is not one "silver bullet", but a range of tools for preventing, diagnosing and dealing with slow queries.
+Neexistuje jedna "stříbrná kulka", ale celá řada nástrojů pro prevenci, diagnostiku a řešení pomalých dotazů.
-##### Query caching
+##### Ukládání dotazů do mezipaměti
-Graph Node caches GraphQL queries by default, which can significantly reduce database load. This can be further configured with the `GRAPH_QUERY_CACHE_BLOCKS` and `GRAPH_QUERY_CACHE_MAX_MEM` settings - read more [here](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
+Graf Uzel ve výchozím nastavení ukládá dotazy GraphQL do mezipaměti, což může výrazně snížit zatížení databáze. To lze dále konfigurovat pomocí nastavení `GRAPH_QUERY_CACHE_BLOCKS` a `GRAPH_QUERY_CACHE_MAX_MEM` - více informací [zde](https://github.com/graphprotocol/graph-node/blob/master/docs/environment-variables.md#graphql-caching).
##### Analysing queries
diff --git a/website/pages/cs/publishing/publishing-a-subgraph.mdx b/website/pages/cs/publishing/publishing-a-subgraph.mdx
index bd8d1ca698a5..2a090f8812f4 100644
--- a/website/pages/cs/publishing/publishing-a-subgraph.mdx
+++ b/website/pages/cs/publishing/publishing-a-subgraph.mdx
@@ -1,33 +1,33 @@
---
-title: Publishing a Subgraph to the Decentralized Network
+title: Zveřejnění podgrafu v decentralizované síti
---
-Once your subgraph has been [deployed to the Subgraph Studio](/deploying/deploying-a-subgraph-to-studio), you have tested it out, and are ready to put it into production, you can then publish it to the decentralized network.
+Jakmile je váš podgraf [nastaven ve Studio podgrafu](/deploying/deploying-a-subgraph-to-studio), otestován a připraven k uvedení do produkčního provozu, můžete jej publikovat v decentralizované síti.
-Publishing a Subgraph to the decentralized network makes it available for [Curators](/network/curating) to begin curating on it, and [Indexers](/network/indexing) to begin indexing it.
+Zveřejněním podgrafu v decentralizované síti jej mohou [kurátoři](/network/curating) začít kurátorsky zpracovávat a [indexátoři](/network/indexing) jej mohou začít indexovat.
-
+
-You can find the list of the supported networks [Here](/developing/supported-networks).
+Seznam podporovaných sítí najdete [Zde](/developing/supported-networks).
-## Publishing a subgraph
+## Zveřejnění podgrafu
-Subgraphs can be published to the decentralized network directly from the Subgraph Studio dashboard by clicking on the **Publish** button. Once a subgraph is published, it will be available to view in the [Graph Explorer](https://thegraph.com/explorer/).
+Podgrafy lze publikovat do decentralizované sítě přímo z ovládacího panelu podgraf Studio kliknutím na tlačítko **Publish**. Jakmile je podgraf publikován, bude k dispozici k zobrazení v [Průzkumníku grafů](https://thegraph.com/explorer/).
-- Subgraphs can be published to Goerli, Arbitrum goerli, Arbitrum One, or Ethereum mainnet.
+- Podgrafy lze publikovat do sítí Goerli, Arbitrum goerli, Arbitrum One nebo Ethereum mainnet.
-- Regardless of the network the subgraph was published on, it can index data on any of the [supported networks](/developing/supported-networks).
+- Bez ohledu na to, v jaké síti byl podgraf publikován, může indexovat data v kterékoli z [podporovaných sítí](/developing/supported-networks).
-- When publishing a new version for an existing subgraph the same rules apply as above.
+- Při publikování nové verze pro existující podgraf platí stejná pravidla jako výše.
-## Curating your subgraph
+## Kurátorství podgrafu
-> It is recommended that you curate your own subgraph with 10,000 GRT to ensure that it is indexed and available for querying as soon as possible.
+> Doporučujeme, abyste si vytvořili vlastní podgraf s 10 000 GRT, abyste zajistili, že bude co nejdříve indexován a dostupný pro dotazování.
-Subgraph Studio enables you to be the first to curate your subgraph by adding GRT to your subgraph's curation pool in the same transaction. When publishing your subgraph, make sure to check the button that says, "Be the first to signal on this subgraph."
+Aplikace podgraf Studio vám umožní být prvním, kdo bude kurátorem vašeho podgrafu, a to přidáním GRT do fondu kurátorů vašeho podgrafu v rámci stejné transakce. Při publikování podgrafu nezapomeňte zaškrtnout tlačítko "Be first to signal on this subgraph" (Buďte první, kdo bude signalizovat na tomto podgrafu)
-
+
-## Updating metadata for a published subgraph
+## Aktualizace metadata publikovaného podgrafu
-Once your subgraph has been published to the decentralized network, you can modify the metadata at any time by making the update in the Subgraph Studio dashboard of the subgraph. After saving the changes and publishing your updates to the network, they will be reflected in The Graph Explorer. This won’t create a new version, as your deployment hasn’t changed.
+Jakmile je podgraf zveřejněn v decentralizované síti, můžete kdykoli změnit metadata provedením aktualizace na ovládacím panelu podgrafu v aplikaci podgraf Studio. Po uložení změn a publikování aktualizací do sítě se tyto změny projeví v Průzkumníku grafů. Tím se nevytvoří nová verze, protože vaše nasazení se nezměnilo.
diff --git a/website/pages/cs/querying/distributed-systems.mdx b/website/pages/cs/querying/distributed-systems.mdx
index 85337206bfd3..e75d5f214bf5 100644
--- a/website/pages/cs/querying/distributed-systems.mdx
+++ b/website/pages/cs/querying/distributed-systems.mdx
@@ -1,14 +1,14 @@
---
-title: Distributed Systems
+title: Distribuované systémy
---
-The Graph is a protocol implemented as a distributed system.
+Graf je protokol implementovaný jako distribuovaný systém.
-Connections fail. Requests arrive out of order. Different computers with out-of-sync clocks and states process related requests. Servers restart. Re-orgs happen between requests. These problems are inherent to all distributed systems but are exacerbated in systems operating at a global scale.
+Připojení selhávají. Požadavky přicházejí mimo pořadí. Různé počítače s nesynchronizovanými hodinami a stavy zpracovávají související požadavky. Servery se restartují. Mezi požadavky dochází k opětovným Re-orgs. Tyto problémy jsou vlastní všem distribuovaným systémům, ale v systémech pracujících v globálním měřítku se ještě zhoršují.
-Consider this example of what may occur if a client polls an Indexer for the latest data during a re-org.
+Vezměme si tento příklad toho, co může nastat, pokud se klient dotazuje indexeru na nejnovější data během re-org.
-1. Indexer ingests block 8
+1. Indexer zpracovat blok 8
2. Request served to the client for block 8
3. Indexer ingests block 9
4. Indexer ingests block 10A
@@ -19,19 +19,19 @@ Consider this example of what may occur if a client polls an Indexer for the lat
9. Indexer ingests block 11
10. Request served to the client for block 11
-From the point of view of the Indexer, things are progressing forward logically. Time is moving forward, though we did have to roll back an uncle block and play the block under consensus forward on top of it. Along the way, the Indexer serves requests using the latest state it knows about at that time.
+Z pohledu indexátora postupují věci logicky vpřed. Čas se posouvá vpřed, i když jsme museli vrátit blok strýce a přehrát na něj blok v rámci konsensu vpřed. Po cestě Indexer obsluhuje požadavky pomocí nejnovějšího stavu, o kterém v danou chvíli ví.
-From the point of view of the client, however, things appear chaotic. The client observes that the responses were for blocks 8, 10, 9, and 11 in that order. We call this the "block wobble" problem. When a client experiences block wobble, data may appear to contradict itself over time. The situation worsens when we consider that Indexers do not all ingest the latest blocks simultaneously, and your requests may be routed to multiple Indexers.
+Z pohledu klienta se však situace jeví jako chaotická. Klient si všimne, že odpovědi se týkaly bloků 8, 10, 9 a 11 v tomto pořadí. Tomu říkáme problém "kmitání bloků". Když klient zažije blokové kmitání, může se zdát, že si data v průběhu času odporují. Situace se ještě zhorší, když uvážíme, že všechny indexátory nepřijímají nejnovější bloky současně a vaše požadavky mohou být směrovány k více indexátorům.
-It is the responsibility of the client and server to work together to provide consistent data to the user. Different approaches must be used depending on the desired consistency as there is no one right program for every problem.
+Je odpovědností klienta a serveru, aby spolupracovali a poskytovali uživateli konzistentní data. V závislosti na požadované konzistenci je třeba použít různé přístupy, protože pro každý problém neexistuje jeden správný program.
-Reasoning through the implications of distributed systems is hard, but the fix may not be! We've established APIs and patterns to help you navigate some common use-cases. The following examples illustrate those patterns but still elide details required by production code (like error handling and cancellation) to not obfuscate the main ideas.
+Uvažovat o důsledcích distribuovaných systémů je těžké, ale náprava možná není! Vytvořili jsme API a vzory, které vám pomohou orientovat se v některých běžných případech použití. Následující příklady ilustrují tyto vzory, ale přesto opomíjejí detaily vyžadované produkčním kódem (jako je zpracování chyb a zrušení), aby nebyly zastřeny hlavní myšlenky.
## Polling for updated data
-The Graph provides the `block: { number_gte: $minBlock }` API, which ensures that the response is for a single block equal or higher to `$minBlock`. If the request is made to a `graph-node` instance and the min block is not yet synced, `graph-node` will return an error. If `graph-node` has synced min block, it will run the response for the latest block. If the request is made to an Edge & Node Gateway, the Gateway will filter out any Indexers that have not yet synced min block and make the request for the latest block the Indexer has synced.
+Graf poskytuje blok `: {Počet_gte:{ number_gte: $minBlock }}` API, které zajišťuje, že odpověď je pro jeden blok rovný nebo vyšší než `$minBlock`. Pokud je požadavek zadán instanci `graph-node` a min. blok ještě není synchronizován, `graph-node` vrátí chybu. Pokud `graph-node` má synchronizovaný minblok, spustí odpověď pro nejnovější blok. Pokud je požadavek zadán bráně Edge & Node, brána odfiltruje všechny indexery, které ještě nesynchronizovaly minblok, a provede požadavek na nejnovější blok, který indexer synchronizoval.
-We can use `number_gte` to ensure that time never travels backward when polling for data in a loop. Here is an example:
+Pomocí `number_gte` můžeme zajistit, aby se čas při dotazování na data ve smyčce nikdy nevracel zpět. Zde je příklad:
```javascript
/// Updates the protocol.paused variable to the latest
@@ -76,9 +76,9 @@ async function updateProtocolPaused() {
## Fetching a set of related items
-Another use-case is retrieving a large set or, more generally, retrieving related items across multiple requests. Unlike the polling case (where the desired consistency was to move forward in time), the desired consistency is for a single point in time.
+Dalším případem použití je načítání velkého souboru nebo obecněji načítání souvisejících položek ve více požadavcích. Na rozdíl od případu dotazování (kde byla požadovaná konzistence pro posun v čase) je požadovaná konzistence pro jeden bod v čase.
-Here we will use the `block: { hash: $blockHash }` argument to pin all of our results to the same block.
+Zde použijeme blok `: { hash: $blockHash }`, abychom všechny naše výsledky připnuli ke stejnému bloku.
```javascript
/// Gets a list of domain names from a single block using pagination
@@ -131,4 +131,4 @@ async function getDomainNames() {
}
```
-Note that in case of a re-org, the client will need to retry from the first request to update the block hash to a non-uncle block.
+Všimněte si, že v případě reorganizace bude muset klient zopakovat první požadavek na aktualizaci hashe bloku na blok, který není strýčkem.
diff --git a/website/pages/cs/querying/graphql-api.mdx b/website/pages/cs/querying/graphql-api.mdx
index 89cda460d58f..315ee3fe4445 100644
--- a/website/pages/cs/querying/graphql-api.mdx
+++ b/website/pages/cs/querying/graphql-api.mdx
@@ -38,7 +38,7 @@ Query all `Token` entities:
When querying a collection, the `orderBy` parameter may be used to sort by a specific attribute. Additionally, the `orderDirection` can be used to specify the sort direction, `asc` for ascending or `desc` for descending.
-#### Example
+#### Příklad
```graphql
{
@@ -282,7 +282,7 @@ The result of such a query will not change over time, i.e., querying at a certai
Note that the current implementation is still subject to certain limitations that might violate these gurantees. The implementation can not always tell that a given block hash is not on the main chain at all, or that the result of a query by block hash for a block that can not be considered final yet might be influenced by a block reorganization running concurrently with the query. They do not affect the results of queries by block hash when the block is final and known to be on the main chain. [This issue](https://github.com/graphprotocol/graph-node/issues/1405) explains what these limitations are in detail.
-#### Example
+#### Příklad
```graphql
{
@@ -298,7 +298,7 @@ Note that the current implementation is still subject to certain limitations tha
This query will return `Challenge` entities, and their associated `Application` entities, as they existed directly after processing block number 8,000,000.
-#### Example
+#### Příklad
```graphql
{
@@ -322,7 +322,7 @@ Fulltext search queries have one required field, `text`, for supplying search te
Fulltext search operators:
-| Symbol | Operator | Description |
+| Symbol | Operator | Popis |
| --- | --- | --- |
| `&` | `And` | For combining multiple search terms into a filter for entities that include all of the provided terms |
| | | `Or` | Queries with multiple search terms separated by the or operator will return all entities with a match from any of the provided terms |
diff --git a/website/pages/cs/querying/managing-api-keys.mdx b/website/pages/cs/querying/managing-api-keys.mdx
index ee7c274bca10..2c81f1993a65 100644
--- a/website/pages/cs/querying/managing-api-keys.mdx
+++ b/website/pages/cs/querying/managing-api-keys.mdx
@@ -1,25 +1,25 @@
---
-title: Managing your API keys
+title: Správa klíčů API
---
-Regardless of whether you’re a dapp developer or a subgraph developer, you’ll need to manage your API keys. This is important for you to be able to query subgraphs because API keys make sure the connections between application services are valid and authorized. This includes authenticating the end user and the device using the application.
+Bez ohledu na to, zda jste vývojář dapp nebo podgraf, budete muset spravovat klíče API. To je důležité pro to, abyste se mohli dotazovat na podgrafy, protože klíče API zajišťují, že spojení mezi službami aplikace jsou platná a autorizovaná. To zahrnuje ověřování koncového uživatele a zařízení, které aplikaci používá.
-The Studio will list out existing API keys, which will give you the ability to manage or delete them.
+Studio zobrazí seznam existujících klíčů API, které můžete spravovat nebo odstraňovat.
-1. The **Overview** section will allow you to:
- - Edit your key name
- - Regenerate API keys
- - View the current usage of the API key with stats:
- - Number of queries
- - Amount of GRT spent
-2. Under **Security**, you’ll be able to opt into security settings depending on the level of control you’d like to have over your API keys. In this section, you can:
- - View and manage the domain names authorized to use your API key
- - Assign subgraphs that can be queried with your API key
-3. Under **Indexer Preference**, you’ll be able to set different preferences for Indexers who are indexing subgraphs that your API key is used for. You can assign up to 5 points for each of these:
- - **Fastest Speed**: Time between the query and the response from an indexer. If you mark this as important we will optimize for fast indexers.
- - **Lowest Price**: The amount paid per query. If you mark this as important we will optimize for the less expensive indexers.
- - **Data Freshness**: How recent the latest block an indexer has processed for the subgraph you are querying. If you mark this as important we will optimize to find the indexers with the freshest data.
- - **Economic Security**: The amount of GRT an indexer can lose if they respond incorrectly to your query. If you mark this as important we will optimize for indexers with a large stake.
+1. Sekce **Přehled** vám umožní:
+ - Úprava názvu klíče
+ - Regenerace klíčů API
+ - Zobrazení aktuálního využití klíče API se statsi:
+ - Počet dotazů
+ - Výše vynaložených GRT
+2. V části **Zabezpečení** budete moci zvolit nastavení zabezpečení podle úrovně kontroly, kterou chcete mít nad klíči API. V této části můžete:
+ - Zobrazení a správa názvů domén oprávněných používat váš klíč API
+ - Přiřazení podgrafů, na které se lze dotazovat pomocí klíče API
+3. V části **Předvolby indexátorů** můžete nastavit různé předvolby pro indexátory, které indexují podgrafy, pro něž se používá váš klíč API. Každému z nich můžete přiřadit až 5 bodů:
+ - **Nejvyšší rychlost**: Doba mezi dotazem a odpovědí indexeru. Pokud tuto hodnotu označíte jako důležitou, budeme optimalizovat pro rychlé indexery.
+ - **Nejnižší cena**: Částka zaplacená za dotaz. Pokud tuto hodnotu označíte jako důležitou, budeme optimalizovat pro levnější indexátory.
+ - **Čerstvost dat**: Jak čerstvý poslední blok indexátor zpracoval pro podgraf, na který se dotazujete. Pokud tuto hodnotu označíte jako důležitou, budeme optimalizovat tak, abychom našli indexery s nejčerstvějšími daty.
+ - **Ekonomická bezpečnost**: Množství GRT, o které může indexátor přijít, pokud na váš dotaz odpoví nesprávně. Pokud tuto hodnotu označíte jako důležitou, budeme optimalizovat pro indexátory s velkým podílem.
4. Under **Budget**, you’ll be able to update the maximum price per query. Note that we have a dynamic setting for that that's based on a volume discounting algorithm. **We strongly recommend using the default settings unless you are experiencing a specific problem.** Otherwise, you can update it under "Set a custom maximum budget". On this page you can also view different KPIs (in GRT and USD):
- Average cost per query
- Failed queries over max price
diff --git a/website/pages/cs/querying/querying-best-practices.mdx b/website/pages/cs/querying/querying-best-practices.mdx
index 98c0ffb72c61..d656ab17bffb 100644
--- a/website/pages/cs/querying/querying-best-practices.mdx
+++ b/website/pages/cs/querying/querying-best-practices.mdx
@@ -1,22 +1,22 @@
---
-title: Querying Best Practices
+title: Osvědčené postupy dotazování
---
-The Graph provides a decentralized way to query data from blockchains.
+Graf poskytuje decentralizovaný způsob dotazování na data z blockchainů.
-The Graph network's data is exposed through a GraphQL API, making it easier to query data with the GraphQL language.
+Data sítě Graf jsou zpřístupněna prostřednictvím GraphQL API, což usnadňuje dotazování na data pomocí jazyka GraphQL.
-This page will guide you through the essential GraphQL language rules and GraphQL queries best practices.
+Tato stránka vás provede základními pravidly jazyka GraphQL a osvědčenými postupy pro dotazy GraphQL.
---
-## Querying a GraphQL API
+## Dotazování GraphQL API
-### The anatomy of a GraphQL query
+### Anatomie dotazu GraphQL
-Unlike REST API, a GraphQL API is built upon a Schema that defines which queries can be performed.
+Na rozdíl od rozhraní REST API je GraphQL API postaveno na schématu, které definuje, jaké dotazy lze provádět.
-For example, a query to get a token using the `token` query will look as follows:
+Například dotaz pro získání tokenu pomocí dotazu `token` bude vypadat takto:
```graphql
query GetToken($id: ID!) {
@@ -27,7 +27,7 @@ query GetToken($id: ID!) {
}
```
-which will return the following predictable JSON response (_when passing the proper `$id` variable value_):
+která vrátí následující předvídatelnou odpověď JSON (_při předání správné `$id`hodnoty proměnné _):
```json
{
@@ -38,9 +38,9 @@ which will return the following predictable JSON response (_when passing the pro
}
```
-GraphQL queries use the GraphQL language, which is defined upon [a specification](https://spec.graphql.org/).
+Dotazy GraphQL používají jazyk GraphQL, který je definován na základě [specifikace](https://spec.graphql.org/).
-The above `GetToken` query is composed of multiple language parts (replaced below with `[...]` placeholders):
+Výše uvedený dotaz `GetToken` se skládá z více jazykových částí (níže nahrazených `[...]`) zástupnými znaky:
```graphql
query [operationName]([variableName]: [variableType]) {
@@ -52,33 +52,33 @@ query [operationName]([variableName]: [variableType]) {
}
```
-While the list of syntactic do's and don'ts is long, here are the essential rules to keep in mind when it comes to writing GraphQL queries:
+I když je seznam syntaktických doporučení a doporučení dlouhý, zde jsou základní pravidla, která je třeba mít na paměti, pokud jde o psaní dotazů GraphQL:
-- Each `queryName` must only be used once per operation.
-- Each `field` must be used only once in a selection (we cannot query `id` twice under `token`)
-- Some `field`s or queries (like `tokens`) return complex types that require a selection of sub-field. Not providing a selection when expected (or providing one when not expected - for example, on `id`) will raise an error. To know a field type, please refer to [The Graph Explorer](/network/explorer).
-- Any variable assigned to an argument must match its type.
-- In a given list of variables, each of them must be unique.
-- All defined variables must be used.
+- Každý `název dotazu` smí být při jedné operaci použit pouze jednou.
+- Každé `pole` musí být ve výběru použito pouze jednou (pod `token` se nemůžeme dvakrát dotazovat na `id`)
+- Některá `pole` nebo dotazy (jako `tokeny`) vracejí složené typy, které vyžadují výběr podpole. Nezadání výběru, když se očekává (nebo zadání výběru, když se neočekává - například u `id`), vyvolá chybu. Chcete-li znát typ pole, podívejte se na [Prohlížeč grafů](/network/explorer). v.
+- Každá proměnná přiřazená argumentu musí odpovídat jeho typu.
+- V daném seznamu proměnných musí být každá z nich jedinečná.
+- Musí být použity všechny definované proměnné.
-Failing to follow the above rules will end with an error from the Graph API.
+Nedodržení výše uvedených pravidel skončí chybou Graf API.
-For a complete list of rules with code examples, please look at our GraphQL Validations guide.
+Kompletní seznam pravidel s příklady kódu naleznete v naší příručce Ověřování GraphQL.
-### Sending a query to a GraphQL API
+### Odeslání dotazu na GraphQL API
-GraphQL is a language and set of conventions that transport over HTTP.
+GraphQL je jazyk a sada konvencí, které se přenášejí přes protokol HTTP.
-It means that you can query a GraphQL API using standard `fetch` (natively or via `@whatwg-node/fetch` or `isomorphic-fetch`).
+To znamená, že se můžete dotazovat na GraphQL API pomocí standardního `fetch` (nativně nebo pomocí `@whatwg-node/fetch` nebo `isomorphic-fetch`).
-However, as stated in ["Querying from an Application"](/querying/querying-from-an-application), we recommend you to use our `graph-client` that supports unique features such as:
+Jak je však uvedeno v části ["Dotazování z aplikace"](/querying/querying-from-an-application), doporučujeme používat našeho `graf-klienta`, který podporuje jedinečné funkce, jako např:
-- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
-- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
-- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
-- Fully typed result
+- Manipulace s podgrafy napříč řetězci: Dotazování z více podgrafů v jednom dotazu
+- [Automatické sledování](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatické stránkování](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Plně zadaný výsledekv
-Here's how to query The Graph with `graph-client`:
+Zde se dozvíte, jak zadat dotaz do Grafu pomocí `graph-client`:
```tsx
import { execute } from '../.graphclient'
@@ -102,17 +102,17 @@ async function main() {
main()
```
-More GraphQL client alternatives are covered in ["Querying from an Application"](/querying/querying-from-an-application).
+Další alternativy klienta GraphQL jsou popsány v ["Dotazování z aplikace"](/querying/querying-from-an-application).
-Now that we covered the basic rules of GraphQL queries syntax, let's now look at the best practices of GraphQL query writing.
+Nyní, když jsme se seznámili se základními pravidly syntaxe dotazů GraphQL, se podíváme na osvědčené postupy psaní dotazů GraphQL.
---
-## Writing GraphQL queries
+## Psaní dotazů GraphQL
-### Always write static queries
+### Vždy pište statické dotazy
-A common (bad) practice is to dynamically build query strings as follows:
+Běžnou (špatnou) praxí je dynamické vytváření řetězců dotazů následujícím způsobem:
```tsx
const id = params.id
@@ -128,14 +128,14 @@ query GetToken {
// Execute query...
```
-While the above snippet produces a valid GraphQL query, **it has many drawbacks**:
+Výše uvedený úryvek sice vytvoří platný dotaz GraphQL, ale **má mnoho nevýhod**:
-- it makes it **harder to understand** the query as a whole
-- developers are **responsible for safely sanitizing the string interpolation**
-- not sending the values of the variables as part of the request parameters **prevent possible caching on server-side**
-- it **prevents tools from statically analyzing the query** (ex: Linter, or type generations tools)
+- je **těžší porozumět** dotazu jako celku
+- vývojáři jsou **zodpovědní za bezpečnou úpravu interpolace řetězců**
+- neposílat hodnoty proměnných jako součást parametrů požadavku **zabránit případnému ukládání do mezipaměti na straně serveru**
+- **zabraňuje nástrojům staticky analyzovat dotaz** (např.: Linter nebo nástroje pro generování typů)
-For this reason, it is recommended to always write queries as static strings:
+Z tohoto důvodu se doporučuje psát dotazy vždy jako statické řetězce:
```tsx
import { execute } from 'your-favorite-graphql-client'
@@ -157,18 +157,18 @@ const result = await execute(query, {
})
```
-Doing so brings **many advantages**:
+To přináší **mnoho výhod**:
-- **Easy to read and maintain** queries
-- The GraphQL **server handles variables sanitization**
-- **Variables can be cached** at server-level
-- **Queries can be statically analyzed by tools** (more on this in the following sections)
+- **Snadné čtení a údržba** dotazů
+- GraphQL **server zpracovává sanitizaci proměnných**
+- **Proměnné lze ukládat do mezipaměti** na úrovni serveru
+- **Nástroje mohou staticky analyzovat dotazy** (více v následujících kapitolách)
-**Note: How to include fields conditionally in static queries**
+**Poznámka: Jak podmíněně zahrnout pole do statických dotazů**
-We might want to include the `owner` field only on a particular condition.
+Pole `vlastník` můžeme chtít zahrnout pouze při splnění určité podmínky.
-For this, we can leverage the `@include(if:...)` directive as follows:
+K tomu můžeme využít direktivu `@include(if:...)` takto:
```tsx
import { execute } from 'your-favorite-graphql-client'
@@ -191,21 +191,21 @@ const result = await execute(query, {
})
```
-Note: The opposite directive is `@skip(if: ...)`.
+Poznámka: Opačným direktivou je `@skip(if: ...)`.
-### Performance tips
+### Výkonnostní tipy
-**"Ask for what you want"**
+**"Požádejte o to, co chcete"**
-GraphQL became famous for its "Ask for what you want" tagline.
+GraphQL se proslavil sloganem „Požádejte o to, co chcete“.
-For this reason, there is no way, in GraphQL, to get all available fields without having to list them individually.
+Z tohoto důvodu neexistuje způsob, jak v GraphQL získat všechna dostupná pole, aniž byste je museli vypisovat jednotlivě.
-When querying GraphQL APIs, always think of querying only the fields that will be actually used.
+Při dotazování na GraphQL vždy myslete na to, abyste dotazovali pouze pole, která budou skutečně použita.
-A common cause of over-fetching is collections of entities. By default, queries will fetch 100 entities in a collection, which is usually much more than what will actually be used, e.g., for display to the user. Queries should therefore almost always set first explicitly, and make sure they only fetch as many entities as they actually need. This applies not just to top-level collections in a query, but even more so to nested collections of entities.
+Častou příčinou nadměrného načítání jsou kolekce entit. Ve výchozím nastavení dotazy načtou 100 entit v kolekci, což je obvykle mnohem více, než kolik se skutečně použije, např. pro zobrazení uživateli. Dotazy by proto měly být téměř vždy nastaveny explicitně jako první a měly by zajistit, aby načítaly pouze tolik entit, kolik skutečně potřebují. To platí nejen pro kolekce nejvyšší úrovně v dotazu, ale ještě více pro vnořené kolekce entit.
-For example, in the following query:
+Například v následujícím dotazu:
```graphql
query listTokens {
@@ -220,13 +220,13 @@ query listTokens {
}
```
-The response could contain 100 transactions for each of the 100 tokens.
+Odpověď může obsahovat 100 transakcí pro každý ze 100 tokenů.
-If the application only needs 10 transactions, the query should explicitly set `first: 10` on the transactions field.
+Pokud aplikace potřebuje pouze 10 transakcí, měl by dotaz explicitně nastavit parametr `first: 10` v poli transakcí.
-**Combining multiple queries**
+**Kombinace více dotazů**
-Your application might require querying multiple types of data as follows:
+Vaše aplikace může vyžadovat dotazování na více typů dat takto:
```graphql
import { execute } from "your-favorite-graphql-client"
@@ -256,9 +256,9 @@ const [tokens, counters] = Promise.all(
)
```
-While this implementation is totally valid, it will require two round trips with the GraphQL API.
+Přestože je tato implementace zcela platná, bude vyžadovat dva požadavky na GraphQL API.
-Fortunately, it is also valid to send multiple queries in the same GraphQL request as follows:
+Naštěstí je také možné odeslat více dotazů v jednom požadavku GraphQL, a to následujícím způsobem:
```graphql
import { execute } from "your-favorite-graphql-client"
@@ -279,13 +279,13 @@ query GetTokensandCounters {
const { result: { tokens, counters } } = execute(query)
```
-This approach will **improve the overall performance** by reducing the time spent on the network (saves you a round trip to the API) and will provide a **more concise implementation**.
+Tento přístup **zlepší celkový výkon** tím, že zkrátí čas strávený na síti (ušetří vám cestu k API) a poskytne **stručnější implementaci**.
-### Leverage GraphQL Fragments
+### Využití fragmentů GraphQL
-A helpful feature to write GraphQL queries is GraphQL Fragment.
+Užitečnou funkcí pro psaní dotazů GraphQL je GraphQL Fragment.
-Looking at the following query, you will notice that some fields are repeated across multiple Selection-Sets (`{ ... }`):
+Při pohledu na následující dotaz si všimnete, že některá pole se opakují ve více výběrových sadách (`{ ... }`):
```graphql
query {
@@ -305,12 +305,12 @@ query {
}
```
-Such repeated fields (`id`, `active`, `status`) bring many issues:
+Taková opakovaná pole (`id`, `active`, `status`) přinášejí mnoho problémů:
-- harder to read for more extensive queries
-- when using tools that generate TypeScript types based on queries (_more on that in the last section_), `newDelegate` and `oldDelegate` will result in two distinct inline interfaces.
+- hůře čitelné pro rozsáhlejší dotazy
+- při použití nástrojů, které generují typy TypeScript na základě dotazů (_více o tom v poslední části_), budou `newDelegate` a `oldDelegate` mít za následek dvě samostatné inline rozhraní.
-A refactored version of the query would be the following:
+Přepracovaná verze dotazu by byla následující:
```graphql
query {
@@ -334,11 +334,11 @@ fragment DelegateItem on Transcoder {
}
```
-Using GraphQL `fragment` will improve readability (especially at scale) but also will result in better TypeScript types generation.
+Použití GraphQL `fragment` zlepší čitelnost (zejména v měřítku), ale také povede k lepšímu generování typůTypeScript.
-When using the types generation tool, the above query will generate a proper `DelegateItemFragment` type (_see last "Tools" section_).
+Při použití nástroje pro generování typů vygeneruje výše uvedený dotaz vhodný typ `DelegateItemFragment` (_viz poslední část "Nástroje"_).
-### GraphQL Fragment do's and don'ts
+### Co dělat a nedělat s fragmenty GraphQL
**Fragment base must be a type**
@@ -356,7 +356,7 @@ fragment MyFragment on BigInt {
Fragments are defined on specific types and should be used accordingly in queries.
-Example:
+Příklad:
```graphql
query {
@@ -417,7 +417,7 @@ fragment VoteWithPoll on Vote {
### GraphQL web-based explorers
-Iterating over queries by running them in your application can be cumbersome. For this reason, don't hesitate to use [The Graph Explorer](https://thegraph.com/explorer) to test your queries before adding them to your application. The Graph Explorer will provide you a preconfigured GraphQL playground to test your queries.
+Iterování dotazů jejich spouštěním ve vaší aplikaci může být těžkopádné. Z tohoto důvodu neváhejte použít [The Graph Explorer](https://thegraph.com/explorer) k otestování svých dotazů před jejich přidáním do aplikace. Průzkumník Graf vám poskytne předkonfigurované hřiště GraphQL pro testování vašich dotazů.
If you are looking for a more flexible way to debug/test your queries, other similar web-based tools are available such as [Altair](https://altair.sirmuel.design/) and [GraphiQL](https://graphiql-online.com/graphiql).
diff --git a/website/pages/cs/querying/querying-by-subgraph-id-vs-deployment-id.mdx b/website/pages/cs/querying/querying-by-subgraph-id-vs-deployment-id.mdx
index 25a955931e7a..446286fc0b45 100644
--- a/website/pages/cs/querying/querying-by-subgraph-id-vs-deployment-id.mdx
+++ b/website/pages/cs/querying/querying-by-subgraph-id-vs-deployment-id.mdx
@@ -1,27 +1,35 @@
---
-title: Subgraph ID vs Deployment ID
+title: ID podgrafu vs. ID nasazení
---
-A subgraph is identified by a Subgraph ID, and each version of the subgraph is identified by a Deployment ID.
+Podgraf je identifikován ID podgrafu a každá verze podgrafu je identifikována ID nasazení.
-When querying a subgraph, either ID can be used, though it is generally suggested that the Deployment ID is used due to its ability to specify a specific version of a subgraph.
+Při dotazování na podgraf lze použít obě ID. Mezi oběma možnostmi však existují některé důležité rozdíly.
-Here are some key differences between the two IDs: 
+
-## Deployment ID
+## ID podgrafu
-The Deployment ID is the IPFS hash of the compiled manifest file, which refers to other files on IPFS instead of relative URLs on the computer. For example, the compiled manifest can be accessed via: `https://api.thegraph.com/ipfs/api/v0/cat?arg=QmQKXcNQQRdUvNRMGJiE2idoTu9fo5F5MRtKztH4WyKxED`. To change the Deployment ID, one can simply update the manifest file, such as modifying the description field as described in the [subgraph manifest documentation](https://github.com/graphprotocol/graph-node/blob/master/docs/subgraph-manifest.md#13-top-level-api).
+ID podgrafu je jedinečný identifikátor podgrafu. Zůstává konstantní ve všech verzích podgrafu. Při dotazování pomocí ID podgrafu se verze neurčuje. To znamená, že verze podgrafu, která odpovídá na váš dotaz, nemusí být nejnovější verzí. Spíše to bude nejnovější verze, která je synchronizovaná a zdravá.
-When queries are made using a subgraph's Deployment ID, we are specifying a version of that subgraph to query. Using the Deployment ID to query a specific subgraph version results in a more sophisticated and robust setup as there is full control over the subgraph version being queried. However, this results in the need of updating the query code manually every time a new version of the subgraph is published.
+Příklad koncového bodu, který používá ID podgrafu:
-Example endpoint that uses Deployment ID:
+`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`
+
+## ID nasazení
+
+Při prohlížení nasazeného podgrafu jsou k dispozici dříve nasazené verze, které lze vybrat. Každá verze v tomto seznamu má jedinečné ID nasazení.
+
+Při zadávání dotazů pomocí ID nasazení zadáváte verzi tohoto podgrafu, na kterou se má dotazovat. To znamená, že verze podgrafu, která odpoví na váš dotaz, bude verze určená ID nasazení.
+
+Příklad koncového bodu, který používá ID nasazení:
`https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/QmfYaVdSSekUeK6expfm47tP8adg3NNdEGnVExqswsSwaB`
-## Subgraph ID
+## Úvahy při použití ID podgrafu vs. ID nasazení
-The Subgraph ID is a unique identifier for a subgraph. It remains constant across all versions of a subgraph. It is recommended to use the Subgraph ID to query the latest version of a subgraph, although there are some caveats.
+Pokud chcete zajistit, aby na vaše dotazy odpovídala nejnovější verze podgrafu, měli byste použít ID nasazení. To vyžaduje, abyste ID nasazení aktualizovali ve svém frontendu vždy, když zveřejníte novou verzi subgrafu.
-Be aware that querying using Subgraph ID may result in queries being responded to by an older version of the subgraph due to the new version needing time to sync. Also, new versions could introduce breaking schema changes.
+Pokud chcete mít jistotu, že se dotazujete na konkrétní verzi podgrafu, měli byste použít také ID nasazení.
-Example endpoint that uses Subgraph ID: `https://gateway-arbitrum.network.thegraph.com/api/[api-key]/subgraphs/id/FL3ePDCBbShPvfRJTaSCNnehiqxsPHzpLud6CpbHoeKW`
+Pokud nepotřebujete zajistit, aby na vaše dotazy odpovídala vždy nejnovější verze podgrafu, můžete použít ID podgrafu. Uvědomte si však, že to může vést k tomu, že na vaše dotazy bude odpovídat starší verze vašeho podgrafu.
diff --git a/website/pages/cs/querying/querying-from-an-application.mdx b/website/pages/cs/querying/querying-from-an-application.mdx
index 30b6c2264d64..9e15c2409837 100644
--- a/website/pages/cs/querying/querying-from-an-application.mdx
+++ b/website/pages/cs/querying/querying-from-an-application.mdx
@@ -1,43 +1,43 @@
---
-title: Querying from an Application
+title: Dotazování z aplikace
---
-Once a subgraph is deployed to the Subgraph Studio or to The Graph Explorer, you will be given the endpoint for your GraphQL API that should look something like this:
+Po nasazení podgrafu do podgraf Studio nebo do Průzkumníka grafů se zobrazí koncový bod GraphQL API, který by měl vypadat následovně:
-**Subgraph Studio (testing endpoint)**
+**Podgraf Studio (testovací koncový bod)**
```sh
Queries (HTTP)
https://api.studio.thegraph.com/query///
```
-**Graph Explorer**
+**Průzkumník grafů**
```sh
Queries (HTTP)
https://gateway.thegraph.com/api//subgraphs/id/
```
-Using the GraphQL endpoint, you can use various GraphQL Client libraries to query the subgraph and populate your app with the data indexed by the subgraph.
+Pomocí koncového bodu GraphQL můžete použít různé knihovny GraphQL Client k dotazování podgrafu a naplnění aplikace daty indexovanými podgraf.
-Here are a couple of the more popular GraphQL clients in the ecosystem and how to use them:
+Zde je několik nejoblíbenějších klientů GraphQL v ekosystému a návod, jak je používat:
-## GraphQL clients
+## Klienti GraphQL
-### Graph client
+### Graf klient
-The Graph is providing it own GraphQL client, `graph-client` that supports unique features such as:
+Graf poskytuje vlastního klienta GraphQL, `graph-client`, který podporuje jedinečné funkce, jako jsou:
-- Cross-chain Subgraph Handling: Querying from multiple subgraphs in a single query
-- [Automatic Block Tracking](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
-- [Automatic Pagination](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
-- Fully typed result
+- Manipulace s podgrafy napříč řetězci: Dotazování z více podgrafů v jednom dotazu
+- [Automatické sledování](https://github.com/graphprotocol/graph-client/blob/main/packages/block-tracking/README.md)
+- [Automatické stránkování](https://github.com/graphprotocol/graph-client/blob/main/packages/auto-pagination/README.md)
+- Plně zadaný výsledekv
-Also integrated with popular GraphQL clients such as Apollo and URQL and compatible with all environments (React, Angular, Node.js, React Native), using `graph-client` will give you the best experience for interacting with The Graph.
+Je také integrován s populárními klienty GraphQL, jako jsou Apollo a URQL, a je kompatibilní se všemi prostředími (React, Angular, Node.js, React Native).Použití `graph-client` vám poskytne nejlepší zážitek z interakce s Graf.
-Let's look at how to fetch data from a subgraph with `graphql-client`.
+Podívejme se, jak načíst data z podgrafu pomocí `graphql-client`.
-To get started, make sure to install The Graph Client CLI in your project:
+Chcete-li začít, nezapomeňte si do projektu nainstalovat Graf Client CLI:
```sh
yarn add -D @graphprotocol/client-cli
@@ -45,7 +45,7 @@ yarn add -D @graphprotocol/client-cli
npm install --save-dev @graphprotocol/client-cli
```
-Define your query in a `.graphql` file (or inlined in your `.js` or `.ts` file):
+Definujte svůj dotaz v souboru `.graphql` (nebo v souboru `.js` nebo `.ts`):
```graphql
query ExampleQuery {
@@ -72,7 +72,7 @@ query ExampleQuery {
}
```
-Then, create a configuration file (called `.graphclientrc.yml`) and point to your GraphQL endpoints provided by The Graph, for example:
+Poté vytvořte konfigurační soubor (nazvaný `.graphclientrc.yml`) a odkažte v něm například na koncové body GraphQL poskytnuté službou Graf:
```yaml
# .graphclientrc.yml
@@ -90,13 +90,13 @@ documents:
- ./src/example-query.graphql
```
-Running the following The Graph Client CLI command will generate typed and ready to use JavaScript code:
+Spuštěním následujícího příkazu Graf Client CLI se vygeneruje kód JavaScriptu připravený k použití:
```sh
graphclient build
```
-Finally, update your `.ts` file to use the generated typed GraphQL documents:
+Nakonec aktualizujte soubor `.ts` tak, aby používal vygenerované dokumenty GraphQL:
```tsx
import React, { useEffect } from 'react'
@@ -134,27 +134,27 @@ function App() {
export default App
```
-**⚠️ Important notice**
+**⚠️ Důležité upozornění**
-`graph-client` is perfectly integrated with other GraphQL clients such as Apollo client, URQL, or React Query; you will [find examples in the official repository](https://github.com/graphprotocol/graph-client/tree/main/examples).
+`graph-client` je dokonale integrován s dalšími klienty GraphQL, jako je klient Apollo, URQL nebo React Query; [příklady najdete v oficiálním repozitáři](https://github.com/graphprotocol/graph-client/tree/main/examples).
-However, if you choose to go with another client, keep in mind that **you won't be able to get to use Cross-chain Subgraph Handling or Automatic Pagination, which are core features for querying The Graph**.
+Pokud se však rozhodnete pro jiného klienta, mějte na paměti, že **nebudete moci používat funkci Cross-chain podgraf Obsluha nebo Automatické pagination, což jsou základní funkce pro dotazování v Grafu**.
-### Apollo client
+### Klient Apollo
-[Apollo client](https://www.apollographql.com/docs/) is the ubiquitous GraphQL client on the front-end ecosystem.
+[Klient Apollo](https://www.apollographql.com/docs/) je všudypřítomný klient GraphQL v ekosystému front-end.
-Available for React, Angular, Vue, Ember, iOS, and Android, Apollo Client, although the heaviest client, brings many features to build advanced UI on top of GraphQL:
+Klient Apollo je k dispozici pro React, Angular, Vue, Ember, iOS a Android, ačkoli je nejtěžším klientem, přináší mnoho funkcí pro budování pokročilého UI na základě GraphQL:
-- advanced error handling
-- pagination
-- data prefetching
-- optimistic UI
-- local state management
+- pokročilé zpracování chyb
+- stránkování
+- přednačítání dat
+- optimistické UI
+- místní státní správa
-Let's look at how to fetch data from a subgraph with Apollo client in a web project.
+Podívejme se, jak načíst data z podgrafu pomocí klienta Apollo ve web projektu.
-First, install `@apollo/client` and `graphql`:
+Nejprve nainstalujte `@apollo/client` a `graphql`:
```sh
npm install @apollo/client graphql
diff --git a/website/pages/cs/querying/querying-the-graph.mdx b/website/pages/cs/querying/querying-the-graph.mdx
index af9dcaaf2477..1f725b18b1d7 100644
--- a/website/pages/cs/querying/querying-the-graph.mdx
+++ b/website/pages/cs/querying/querying-the-graph.mdx
@@ -1,14 +1,14 @@
---
-title: Querying The Graph
+title: Dotazování na graf
---
-With the subgraph deployed, visit the [Graph Explorer](https://thegraph.com/explorer) to open up a [GraphiQL](https://github.com/graphql/graphiql) interface where you can explore the deployed GraphQL API for the subgraph by issuing queries and viewing the schema.
+Po nasazení podgrafu navštivte [Graph Explorer](https://thegraph.com/explorer) a otevřete rozhraní [GraphiQL](https://github.com/graphql/graphiql), kde můžete prozkoumat nasazené rozhraní GraphQL API pro podgraf zadáváním dotazů a zobrazením schéma.
-An example is provided below, but please see the [Query API](/querying/graphql-api) for a complete reference on how to query the subgraph's entities.
+Níže je uveden příklad, ale kompletní informace o tom, jak se dotazovat na entity podgrafu, najdete v [Query API](/querying/graphql-api).
-## Example
+## Příklad
-This query lists all the counters our mapping has created. Since we only create one, the result will only contain our one `default-counter`:
+Tento dotaz obsahuje seznam všech čítačů, které naše mapování vytvořilo. Protože jsme vytvořili pouze jeden, výsledek bude obsahovat pouze náš jeden `default-counter`:
```graphql
{
@@ -19,14 +19,14 @@ This query lists all the counters our mapping has created. Since we only create
}
```
-## Using The Graph Explorer
+## Používání Průzkumníka grafů
-Each subgraph published to the decentralized Graph Explorer has a unique query URL that you can find by navigating to the subgraph details page and clicking on the "Query" button on the top right corner. This will open a side pane that will give you the unique query URL of the subgraph as well as some instructions about how to query it.
+Každý podgraf publikovaný v decentralizovaném Průzkumníku grafů má jedinečnou adresu URL dotazu, kterou najdete po přechodu na stránku s podrobnostmi o podgrafu a kliknutím na tlačítko "Dotaz" v pravém horním rohu. Tím se otevře postranní panel, který vám poskytne jedinečnou adresu URL dotazu podgrafu a také několik pokynů, jak se na něj dotazovat.
-
+
-As you can notice, this query URL must use a unique API key. You can create and manage your API keys in the [Subgraph Studio](https://thegraph.com/studio) in the "API Keys" section. Learn more about how to use Subgraph Studio [here](/deploying/subgraph-studio).
+Jak si můžete všimnout, tato adresa URL dotazu musí používat jedinečný klíč API. Klíče API můžete vytvářet a spravovat v [podgraf Studio](https://thegraph.com/studio) v části "Klíče API". Více informací o tom, jak používat aplikaci Subgraph Studio, se dozvíte [zde](/deploying/subgraph-studio).
-Querying subgraphs using your API keys will generate query fees that will be paid in GRT. You can learn more about billing [here](/billing).
+Dotazování na podgrafy pomocí vašich klíčů API bude generovat poplatky za dotazování, které se platí v GRT. Více informací o účtování se dozvíte [zde](/billing).
-You can also use the GraphQL playground in the "Playground" tab to query a subgraph within The Graph Explorer.
+K dotazování podgrafu v rámci Průzkumníka grafu můžete také použít hřiště GraphQL na kartě "Hřiště".
diff --git a/website/pages/cs/querying/querying-the-hosted-service.mdx b/website/pages/cs/querying/querying-the-hosted-service.mdx
deleted file mode 100644
index f00ff226ce09..000000000000
--- a/website/pages/cs/querying/querying-the-hosted-service.mdx
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Querying the Hosted Service
----
-
-With the subgraph deployed, visit the [hosted service](https://thegraph.com/hosted-service/) to open up a [GraphiQL](https://github.com/graphql/graphiql) interface where you can explore the deployed GraphQL API for the subgraph by issuing queries and viewing the schema.
-
-An example is provided below, but please see the [Query API](/querying/graphql-api) for a complete reference on how to query the subgraph's entities.
-
-## Example
-
-This query lists all the counters our mapping has created. Since we only create one, the result will only contain our one `default-counter`:
-
-```graphql
-{
- counters {
- id
- value
- }
-}
-```
-
-## Using the hosted service
-
-The Graph Explorer and its GraphQL playground is a useful way to explore and query deployed subgraphs on the hosted service.
-
-Some of the main features are detailed below:
-
-
diff --git a/website/pages/cs/querying/querying-with-python.mdx b/website/pages/cs/querying/querying-with-python.mdx
index 4fb618510070..5d92e1d18aa1 100644
--- a/website/pages/cs/querying/querying-with-python.mdx
+++ b/website/pages/cs/querying/querying-with-python.mdx
@@ -2,13 +2,13 @@
title: Query The Graph with Python and Subgrounds
---
-Subgrounds is an intuitive Python library for querying subgraphs, built by [Playgrounds](https://playgrounds.network/). It allows you to directly connect subgraph data to a Python data environment, letting you use libraries like [pandas](https://pandas.pydata.org/) to perform data analysis!
+Subgrounds je intuitivní knihovna Pythonu pro dotazování na podgrafy, vytvořená [Playgrounds](https://playgrounds.network/). Umožňuje přímo připojit data subgrafů k datovému prostředí Pythonu, což vám umožní používat knihovny jako [pandas](https://pandas.pydata.org/) k provádění analýzy dat!
-Subgrounds offers a simple Pythonic API for building GraphQL queries, automates tedious workflows such as pagination, and empowers advanced users through controlled schema transformations.
+Subgrounds nabízí jednoduché Pythonic API pro vytváření dotazů GraphQL, automatizuje zdlouhavé pracovní postupy, jako je stránkování, a umožňuje pokročilým uživatelům řízené transformace schémat.
-## Getting Started
+## Začínáme
-Subgrounds requires Python 3.10 or higher and is available on [pypi](https://pypi.org/project/subgrounds/).
+Subgrounds vyžaduje Python 3.10 nebo vyšší a je k dispozici na [pypi](https://pypi.org/project/subgrounds/).
```bash
pip install --upgrade subgrounds
@@ -16,41 +16,41 @@ pip install --upgrade subgrounds
python -m pip install --upgrade subgrounds
```
-Once installed, you can test out subgrounds with the following query. The following example grabs a subgraph for the Aave v2 protocol and queries the top 5 markets ordered by TVL (Total Value Locked), selects their name and their TVL (in USD) and returns the data as a pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
+Po instalaci můžete vyzkoušet podklady pomocí následujícího dotazu. Následující příklad uchopí podgraf pro protokol Aave v2 a dotazuje se na 5 největších trhů seřazených podle TVL (Total Value Locked), vybere jejich název a jejich TVL (v USD) a vrátí data jako pandas [DataFrame](https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.html#pandas.DataFrame).
```python
from subgrounds import Subgrounds
sg = Subgrounds()
-# Load the subgraph
+# Načtení podgrafu
aave_v2 = sg.load_subgraph(
"https://api.thegraph.com/subgraphs/name/messari/aave-v2-ethereum")
-# Construct the query
+# Sestavte dotaz
latest_markets = aave_v2.Query.markets(
orderBy=aave_v2.Market.totalValueLockedUSD,
- orderDirection='desc',
+ orderDirection="desc",
first=5,
)
-# Return query to a dataframe
+# Vrátit dotaz do datového rámce
sg.query_df([
latest_markets.name,
latest_markets.totalValueLockedUSD,
])
```
-## Documentation
+## Dokumentace
-Subgrounds is built and maintained by the [Playgrounds](https://playgrounds.network/) team and can be accessed on the [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
+Subgrounds je vytvořen a spravován týmem [Playgrounds](https://playgrounds.network/) a je k dispozici na stránce [Playgrounds docs](https://docs.playgrounds.network/subgrounds).
-Since subgrounds has a large feature set to explore, here are some helpful starting places:
+Vzhledem k tomu, že subgrounds má rozsáhlou sadu funkcí, které je třeba prozkoumat, uvádíme několik užitečných výchozích bodů:
-- [Getting Started with Querying](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
- - A good first step for how to build queries with subgrounds.
-- [Building Synthetic Fields](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
- - A gentle introduction to defining synthetic fields that transform data defined from the schema.
-- [Concurrent Queries](https://docs.playgrounds.network/subgrounds/getting_started/async/)
- - Learn how to level up your queries by parallelizing them.
-- [Exporting Data to CSVs](https://docs.playgrounds.network/subgrounds/faq/exporting/)
- - A quick article on how to seemlessly save your data as CSVs for further analysis.
+- [Začínáme s dotazováním](https://docs.playgrounds.network/subgrounds/getting_started/basics/)
+ - Dobrý první krok k tomu, jak vytvářet dotazy s subgrounds.
+- [Budování syntetických polí](https://docs.playgrounds.network/subgrounds/getting_started/synthetic_fields/)
+ - Jemný úvod do definování syntetických polí, která transformují data definovaná ze schématu.
+- [Souběžné dotazy](https://docs.playgrounds.network/subgrounds/getting_started/async/)
+ - Zjistěte, jak zvýšit úroveň dotazů jejich paralelizací.
+- [Export dat do CSV](https://docs.playgrounds.network/subgrounds/faq/exporting/)
+ - Stručný článek o tom, jak bez problémů ukládat data ve formátu CSV pro další analýzu.
diff --git a/website/pages/cs/quick-start.mdx b/website/pages/cs/quick-start.mdx
index 54247bed1aad..13af4b54b95d 100644
--- a/website/pages/cs/quick-start.mdx
+++ b/website/pages/cs/quick-start.mdx
@@ -1,28 +1,28 @@
---
-title: Quick Start
+title: Rychlé spuštění
---
-This guide will quickly take you through how to initialize, create, and deploy your subgraph to the Subgraph Studio or the [hosted service](#hosted-service).
+This guide will quickly take you through how to initialize, create, and deploy your subgraph to the Subgraph Studio or the hosted service.
Ensure that your subgraph will be indexing data from a [supported network](/developing/supported-networks).
-This guide is written assuming that you have:
+Tato příručka je napsána za předpokladu, že máte:
-- A smart contract address on the network of your choice
-- GRT to curate your subgraph
-- A crypto wallet
+- Adresa chytrého kontraktu v síti podle vašeho výběru
+- GRT ke kurátorství vašeho podgrafu
+- Kryptopeněženka
-## 1. Create a subgraph on Subgraph Studio
+## 1. Vytvoření podgrafu v Subgraph Studio
Go to the [Subgraph Studio](https://thegraph.com/studio/) and connect your wallet.
-Once connected, you can begin by clicking “create a subgraph.” Select the network of your choice and click continue.
+Po připojení můžete začít kliknutím na tlačítko "create a subgraph". Vyberte vybranou síť a klikněte na tlačítko pokračovat.
-## 2. Install the Graph CLI
+## 2. Nainstalujte Graph CLI
The Graph CLI is written in JavaScript and you will need to have either `npm` or `yarn` installed to use it.
-On your local machine, run one of the following commands:
+V místním počítači spusťte jeden z následujících příkazů:
Using [npm](https://www.npmjs.com/):
@@ -36,53 +36,53 @@ Using [yarn](https://yarnpkg.com/):
yarn global add @graphprotocol/graph-cli
```
-## 3. Initialize your Subgraph
+## 3. Inicializujte podgraf
> You can find commands for your specific subgraph on the subgraph page in [Subgraph Studio](https://thegraph.com/studio/).
-When you initialize your subgraph, the CLI tool will ask you for the following information:
+Při inicializaci podgrafu vás nástroj CLI požádá o následující informace:
-- Protocol: choose the protocol your subgraph will be indexing data from
-- Subgraph slug: create a name for your subgraph. Your subgraph slug is an identifier for your subgraph.
-- Directory to create the subgraph in: choose your local directory
-- Ethereum network(optional): you may need to specify which EVM-compatible network your subgraph will be indexing data from
-- Contract address: Locate the smart contract address you’d like to query data from
-- ABI: If the ABI is not autopopulated, you will need to input it manually as a JSON file
-- Start Block: it is suggested that you input the start block to save time while your subgraph indexes blockchain data. You can locate the start block by finding the block where your contract was deployed.
-- Contract Name: input the name of your contract
-- Index contract events as entities: it is suggested that you set this to true as it will automatically add mappings to your subgraph for every emitted event
-- Add another contract(optional): you can add another contract
+- Protokol: vyberte protokol, ze kterého bude váš podgraf indexovat data.
+- Slug podgrafu: vytvořte název podgrafu. Váš podgraf slug je identifikátor vašeho podgrafu.
+- Adresář pro vytvoření podgrafu: vyberte místní adresář.
+- Ethereum síť (nepovinné): možná budete muset zadat, ze které sítě kompatibilní s EVM bude váš subgraf indexovat data.
+- Adresa zakázky: Vyhledejte adresu chytré smlouvy, ze které se chcete dotazovat na data.
+- ABI: Pokud se ABI nevyplňuje automaticky, je třeba jej zadat ručně jako soubor JSON.
+- Počáteční blok: Doporučuje se zadat počáteční blok, abyste ušetřili čas, zatímco váš subgraf indexuje data blockchainu. Počáteční blok můžete vyhledat tak, že najdete blok, ve kterém byl váš kontrakt nasazen.
+- Název smlouvy: zadejte název své smlouvy.
+- Indexovat události smlouvy jako entity: doporučujeme nastavit tuto hodnotu na true, protože se automaticky přidá mapování do vašeho subgrafu pro každou emitovanou událost
+- Přidat další smlouvu(nepovinné): můžete přidat další smlouvu
-Initialize your subgraph from an existing contract by running the following command:
+Inicializujte podgraf z existující smlouvy spuštěním následujícího příkazu:
```sh
graph init --studio
```
-See the following screenshot for an example for what to expect when initializing your subgraph:
+Na následujícím snímku najdete příklad toho, co můžete očekávat při inicializaci podgrafu:
-## 4. Write your Subgraph
+## 4. Napište svůj podgraf
-The previous commands create a scaffold subgraph that you can use as a starting point for building your subgraph. When making changes to the subgraph, you will mainly work with three files:
+Předchozí příkazy vytvořily podgraf lešení, který můžete použít jako výchozí bod pro sestavení podgrafu. Při provádění změn v podgrafu budete pracovat především se třemi soubory:
-- Manifest (subgraph.yaml) - The manifest defines what datasources your subgraphs will index.
-- Schema (schema.graphql) - The GraphQL schema defines what data you wish to retrieve from the subgraph.
-- AssemblyScript Mappings (mapping.ts) - This is the code that translates data from your datasources to the entities defined in the schema.
+- Manifest (subgraph.yaml) - Manifest definuje, jaké datové zdroje budou vaše podgrafy indexovat.
+- Schéma (schema.graphql) - Schéma GraphQL definuje, jaká data chcete z podgrafu získat.
+- AssemblyScript Mapování (mapping.ts) - Jedná se o kód, který převádí data z datových zdrojů na entity definované ve schématu.
-For more information on how to write your subgraph, see [Creating a Subgraph](/developing/creating-a-subgraph).
+Další informace o zápisu podgrafu naleznete v části [Creating a Subgraph](/developing/creating-a-subgraph).
-## 5. Deploy to the Subgraph Studio
+## 5. Nasazení do studia Subgraph Studio
-Once your subgraph is written, run the following commands:
+Jakmile je podgraf napsán, spusťte následující příkazy:
```sh
$ graph codegen
$ graph build
```
-- Authenticate and deploy your subgraph. The deploy key can be found on the Subgraph page in Subgraph Studio.
+- Ověřte a nasaďte svůj podgraf. Klíč k nasazení najdete na stránce Subgraph ve Studiu Subgraph.
```sh
$ graph auth --studio
@@ -91,11 +91,11 @@ $ graph deploy --studio
You will be asked for a version label. It's strongly recommended to use [semver](https://semver.org/) for versioning like `0.0.1`. That said, you are free to choose any string as version such as:`v1`, `version1`, `asdf`.
-## 6. Test your subgraph
+## 6. Otestujte svůj podgraf
-You can test your subgraph by making a sample query in the playground section.
+Svůj podgraf můžete otestovat pomocí vzorového dotazu v sekci hřiště.
-The logs will tell you if there are any errors with your subgraph. The logs of an operational subgraph will look like this:
+V protokolech se dozvíte, zda se v podgrafu vyskytly nějaké chyby. Protokoly funkčního podgrafu budou vypadat takto:
@@ -143,26 +143,26 @@ If your subgraph is failing, you can query the subgraph health by using the Grap
}
```
-## 7. Publish Your Subgraph to The Graph’s Decentralized Network
+## 7. Zveřejnění subgrafu v decentralizované síti grafu
-Once your subgraph has been deployed to the Subgraph Studio, you have tested it out, and are ready to put it into production, you can then publish it to the decentralized network.
+Jakmile je váš subgraf nasazen do Subgraph Studia, otestován a připraven k uvedení do produkčního provozu, můžete jej publikovat v decentralizované síti.
-In the Subgraph Studio, click on your subgraph. On the subgraph’s page, you will be able to click the publish button on the top right.
+Ve Studio podgrafů klikněte na svůj podgraf. Na stránce podgrafu budete moci kliknout na tlačítko publikovat vpravo nahoře.
Select the network you would like to publish your subgraph to. It is recommended to publish subgraphs to Arbitrum One to take advantage of the [faster transaction speeds and lower gas costs](/arbitrum/arbitrum-faq).
-Before you can query your subgraph, Indexers need to begin serving queries on it. In order to streamline this process, you can curate your own subgraph using GRT.
+Než se budete moci dotazovat na podgraf, je třeba, aby na něm indexery začaly obsluhovat dotazy. Abyste tento proces zefektivnili, můžete si pomocí GRT vytvořit vlastní podgraf.
-At the time of writing, it is recommended that you curate your own subgraph with 10,000 GRT to ensure that it is indexed and available for querying as soon as possible.
+V době psaní tohoto článku se doporučuje, abyste si vytvořili vlastní podgraf s 10,000 GRT, abyste zajistili, že bude co nejdříve indexován a dostupný pro dotazování.
-To save on gas costs, you can curate your subgraph in the same transaction that you published it by selecting this button when you publish your subgraph to The Graph’s decentralized network:
+Abyste ušetřili náklady na benzín, můžete svůj subgraf kurátorovat ve stejné transakci, v níž jste ho publikovali, a to výběrem tohoto tlačítka při publikování subgrafu do decentralizované sítě The Graph:
-## 8. Query your Subgraph
+## 8. Dotaz na podgraf
-Now, you can query your subgraph by sending GraphQL queries to your subgraph’s Query URL, which you can find by clicking on the query button.
+Nyní se můžete dotazovat na svůj podgraf odesláním dotazů GraphQL na adresu URL dotazu podgrafu, kterou najdete kliknutím na tlačítko dotazu.
-You can query from your dapp if you don't have your API key via the free, rate-limited temporary query URL that can be used for development and staging.
+Pokud nemáte svůj klíč API, můžete se ze své aplikace dotazovat prostřednictvím bezplatné dočasné adresy URL pro dotazy s omezenou sazbou, kterou lze použít pro vývoj a staging.
-For more information about querying data from your subgraph, read more [here](../querying/querying-the-graph/).
+For more information about querying data from your subgraph, read more [here](/querying/querying-the-graph/).
diff --git a/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx b/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
index 85f6903a6c69..8997891e0538 100644
--- a/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
+++ b/website/pages/cs/release-notes/assemblyscript-migration-guide.mdx
@@ -1,50 +1,50 @@
---
-title: AssemblyScript Migration Guide
+title: Průvodce migrací AssemblyScript
---
-Up until now, subgraphs have been using one of the [first versions of AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Finally we've added support for the [newest one available](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
+Dosud se pro subgrafy používala jedna z [prvních verzí AssemblyScript](https://github.com/AssemblyScript/assemblyscript/tree/v0.6) (v0.6). Konečně jsme přidali podporu pro [nejnovější dostupnou verzi](https://github.com/AssemblyScript/assemblyscript/tree/v0.19.10) (v0.19.10)! 🎉
-That will enable subgraph developers to use newer features of the AS language and standard library.
+To umožní vývojářům podgrafů používat novější funkce jazyka AS a standardní knihovny.
-This guide is applicable for anyone using `graph-cli`/`graph-ts` below version `0.22.0`. If you're already at a higher than (or equal) version to that, you've already been using version `0.19.10` of AssemblyScript 🙂
+Tato příručka platí pro všechny, kteří používají `graph-cli`/`graph-ts` pod verzí `0.22.0`. Pokud již máte vyšší (nebo stejnou) verzi, používáte již verzi `0.19.10` AssemblyScript 🙂
-> Note: As of `0.24.0`, `graph-node` can support both versions, depending on the `apiVersion` specified in the subgraph manifest.
+> Poznámka: Od verze `0.24.0` může `graph-node` podporovat obě verze v závislosti na `apiVersion` uvedené v manifestu podgrafu.
-## Features
+## Funkce
-### New functionality
+### Nové funkce
-- `TypedArray`s can now be built from `ArrayBuffer`s by using the [new `wrap` static method](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
-- New standard library functions: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`and `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Added support for x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
-- Added `StaticArray`, a more efficient array variant ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
-- Added `Array#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-- Implemented `radix` argument on `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
-- Added support for separators in floating point literals ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
-- Added support for first class functions ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
-- Add builtins: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
-- Implement `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-- Added support for template literal strings ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
-- Add `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
-- Add `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
-- Add `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
-- Add `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
+- `TypedArray`s lze nyní sestavit z `ArrayBuffer`s pomocí [nové `wrap` statické metody](https://www.assemblyscript.org/stdlib/typedarray.html#static-members) ([v0.8.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.8.1))
+- Nové funkce standardní knihovny: `String#toUpperCase`, `String#toLowerCase`, `String#localeCompare`a `TypedArray#set` ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Přidána podpora pro x instanceof GenericClass ([v0.9.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.2))
+- Přidána `StaticArray`, efektivnější varianta pole ([v0.9.3](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.3))
+- Přidáno `Array#flat` ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Implementován argument `radix` na `Number#toString` ([v0.10.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.1))
+- Přidána podpora oddělovačů v literálech s plovoucí desetinnou čárkou ([v0.13.7](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.13.7))
+- Přidána podpora funkcí první třídy ([v0.14.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.0))
+- Přidání vestavěných: `i32/i64/f32/f64.add/sub/mul` ([v0.14.13](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.14.13))
+- Implementovat `Array/TypedArray/String#at` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- Přidána podpora literálních řetězců šablon ([v0.18.17](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.17))
+- Přidat `encodeURI(Component)` and `decodeURI(Component)` ([v0.18.27](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.27))
+- Přidat `toString`, `toDateString` and `toTimeString` to `Date` ([v0.18.29](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.29))
+- Přidat `toUTCString` for `Date` ([v0.18.30](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.30))
+- Přidat `nonnull/NonNullable` builtin type ([v0.19.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.19.2))
-### Optimizations
+### Optimalizace
-- `Math` functions such as `exp`, `exp2`, `log`, `log2` and `pow` have been replaced by faster variants ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Slightly optimize `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
-- Cache more field accesses in std Map and Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
-- Optimize for powers of two in `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
+- `Math` funkce jako `exp`, `exp2`, `log`, `log2` a `pow` byly nahrazeny rychlejšími variantami ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Mírná optimalizace `Math.mod` ([v0.17.1](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.1))
+- Vyrovnávací paměť pro více přístupů k polím std Map a Set ([v0.17.8](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.17.8))
+- Optimalizace pro mocniny dvou v `ipow32/64` ([v0.18.2](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.18.2))
-### Other
+### Jiný
-- The type of an array literal can now be inferred from its contents ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
-- Updated stdlib to Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
+- Typ literálu pole lze nyní odvodit z jeho obsahu ([v0.9.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.9.0))
+- Aktualizace stdlib na Unicode 13.0.0 ([v0.10.0](https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.10.0))
-## How to upgrade?
+## Jak provést upgrade?
-1. Change your mappings `apiVersion` in `subgraph.yaml` to `0.0.6`:
+1. Změňte mapování `apiVersion` v `subgraph.yaml` na `0.0.6`:
```yaml
...
@@ -56,7 +56,7 @@ dataSources:
...
```
-2. Update the `graph-cli` you're using to the `latest` version by running:
+2. Aktualizujte používaný `graph-cli` na `nejnovější` verzi spuštěním:
```bash
# if you have it globally installed
@@ -66,20 +66,20 @@ npm install --global @graphprotocol/graph-cli@latest
npm install --save-dev @graphprotocol/graph-cli@latest
```
-3. Do the same for `graph-ts`, but instead of installing globally, save it in your main dependencies:
+3. Totéž proveďte pro `graph-ts`, ale místo globální instalace jej uložte do hlavních závislostí:
```bash
npm install --save @graphprotocol/graph-ts@latest
```
-4. Follow the rest of the guide to fix the language breaking changes.
-5. Run `codegen` and `deploy` again.
+4. Postupujte podle zbytku příručky a opravte změny, které narušují jazyk.
+5. Znovu spusťte `codegen` a `deploy`.
-## Breaking changes
+## Prolomení změn
### Nullability
-On the older version of AssemblyScript, you could create code like this:
+Ve starší verzi AssemblyScript bylo možné vytvořit kód takto:
```typescript
function load(): Value | null { ... }
@@ -88,7 +88,7 @@ let maybeValue = load();
maybeValue.aMethod();
```
-However on the newer version, because the value is nullable, it requires you to check, like this:
+V novější verzi je však hodnota nulovatelná a je nutné ji zkontrolovat takto:
```typescript
let maybeValue = load()
@@ -98,7 +98,7 @@ if (maybeValue) {
}
```
-Or force it like this:
+Nebo si to vynuťte takto:
```typescript
let maybeValue = load()! // breaks in runtime if value is null
@@ -106,11 +106,11 @@ let maybeValue = load()! // breaks in runtime if value is null
maybeValue.aMethod()
```
-If you are unsure which to choose, we recommend always using the safe version. If the value doesn't exist you might want to just do an early if statement with a return in you subgraph handler.
+Pokud si nejste jisti, kterou verzi zvolit, doporučujeme vždy použít bezpečnou verzi. Pokud hodnota neexistuje, možná budete chtít provést pouze časný příkaz if s návratem v obsluze podgrafu.
-### Variable Shadowing
+### Proměnlivé stínování
-Before you could do [variable shadowing](https://en.wikipedia.org/wiki/Variable_shadowing) and code like this would work:
+Dříve jste mohli udělat [stínování proměnné](https://en.wikipedia.org/wiki/Variable_shadowing) a kód jako tento by fungoval:
```typescript
let a = 10
@@ -118,7 +118,7 @@ let b = 20
let a = a + b
```
-However now this isn't possible anymore, and the compiler returns this error:
+Nyní to však již není možné a překladač vrací tuto chybu:
```typescript
ERROR TS2451: Cannot redeclare block-scoped variable 'a'
@@ -128,11 +128,11 @@ ERROR TS2451: Cannot redeclare block-scoped variable 'a'
in assembly/index.ts(4,3)
```
-You'll need to rename your duplicate variables if you had variable shadowing.
+Pokud jste použili stínování proměnných, musíte duplicitní proměnné přejmenovat.
-### Null Comparisons
+### Nulová srovnání
-By doing the upgrade on your subgraph, sometimes you might get errors like these:
+Při aktualizaci podgrafu může někdy dojít k těmto chybám:
```typescript
ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' is not assignable to type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt'.
@@ -141,7 +141,7 @@ ERROR TS2322: Type '~lib/@graphprotocol/graph-ts/common/numbers/BigInt | null' i
in src/mappings/file.ts(41,21)
```
-To solve you can simply change the `if` statement to something like this:
+Pro vyřešení můžete jednoduše změnit příkaz `if` na něco takového:
```typescript
if (!decimals) {
@@ -151,23 +151,23 @@ To solve you can simply change the `if` statement to something like this:
if (decimals === null) {
```
-The same applies if you're doing != instead of ==.
+Totéž platí, pokud místo == použijete !=.
### Casting
-The common way to do casting before was to just use the `as` keyword, like this:
+Dříve se běžně používalo klíčové slovo `jako`, například takto:
```typescript
let byteArray = new ByteArray(10)
let uint8Array = byteArray as Uint8Array // equivalent to: byteArray
```
-However this only works in two scenarios:
+To však funguje pouze ve dvou případech:
-- Primitive casting (between types such as `u8`, `i32`, `bool`; eg: `let b: isize = 10; b as usize`);
-- Upcasting on class inheritance (subclass → superclass)
+- Primitivní casting (mezi typy jako `u8`, `i32`, `bool`; např: `let b: isize = 10; b jako usize`);
+- Upcasting na dědičnost tříd (podtřída → nadtřída)
-Examples:
+Příklady:
```typescript
// primitive casting
@@ -184,10 +184,10 @@ let bytes = new Bytes(2)
// bytes // same as: bytes as Uint8Array
```
-There are two scenarios where you may want to cast, but using `as`/`var` **isn't safe**:
+Existují dva scénáře, kdy můžete chtít provést obsazení, ale použití `jako`/`var` **není bezpečné**:
-- Downcasting on class inheritance (superclass → subclass)
-- Between two types that share a superclass
+- Downcasting při dědění tříd (nadtřída → podtřída)
+- Mezi dvěma typy, které mají společnou nadtřídu
```typescript
// downcasting on class inheritance
@@ -206,7 +206,7 @@ let bytes = new Bytes(2)
// bytes // breaks in runtime :(
```
-For those cases, you can use the `changetype