diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..1671a39aa88 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: Merkle Patricia Trie +description: "Úvod do Merkle Patricia Trie." +lang: cs +sidebarDepth: 2 +--- + +Stav Etherea (tj. souhrn všech účtů, zůstatků a smart kontraktů) je zakódován do speciální verze datové struktury, která je obecně v informatice známá jako Merkle tree. Tato struktura je užitečná pro mnoho aplikací v kryptografii, protože vytváří ověřitelný vztah mezi všemi jednotlivými datovými prvky propletenými ve stromu, což vede k jediné **kořenové** hodnotě, kterou lze použít k prokazování různých skutečností o datech. + +Datová struktura Etherea je „modifikovaný Merkle-Patricia Trie“, pojmenovaný tak proto, že si půjčuje některé vlastnosti z PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) a protože je navržen pro efektivní re**trie**val (vyhledávání) položek, které tvoří stav Etherea. + +Datová struktura Merkle-Patricia trie je deterministická a kryptograficky ověřitelná: Jediný způsob, jak vygenerovat kořen stavu, je jeho výpočet z každé jednotlivé části stavu, a dva identické stavy lze snadno prokázat porovnáním kořenového haše a hašů, které k němu vedly (_Merkleho důkaz_). Naopak není možné vytvořit dva různé stavy se stejným kořenovým hashem a jakýkoli pokus o modifikaci stavu s jinými hodnotami povede k odlišnému kořenovému hashi stavu. Teoreticky tato struktura poskytuje „svatý grál“ efektivity `O(log(n))` pro vkládání, vyhledávání a mazání. + +V blízké budoucnosti Ethereum plánuje přejít na strukturu [stromu Verkle](/roadmap/verkle-trees), což otevře mnoho nových možností pro budoucí vylepšení protokolu. + +## Předpoklady {#prerequisites} + +Pro lepší pochopení této stránky je užitečné mít základní znalosti o [haších](https://en.wikipedia.org/wiki/Hash_function), [Merkleho stromech](https://en.wikipedia.org/wiki/Merkle_tree), [trie](https://en.wikipedia.org/wiki/Trie) a [serializaci](https://en.wikipedia.org/wiki/Serialization). Tento článek začíná popisem základního [radixového stromu](https://en.wikipedia.org/wiki/Radix_tree) a postupně zavádí úpravy nezbytné pro optimalizovanější datovou strukturu Etherea. + +## Základní radixové trie {#basic-radix-tries} + +V základním radixovém trie vypadá každý síťový uzel následovně: + +``` + [i_0, i_1 ... i_n, value] +``` + +Kde `i_0 ...` i_n`představují symboly abecedy (často binární nebo hexadecimální),`value`je konečná hodnota v uzlu a hodnoty v`i_0, i_1 ...` i_n` slotech jsou buď `NULL`, nebo ukazatele na (v našem případě haše) jiné uzly. To tvoří základní úložiště `(key, value)`. + +Řekněme, že chcete použít strukturu radixového stromu pro uchování uspořádání nad sadou párů key-value. Chcete-li najít hodnotu aktuálně namapovanou na klíč `dog` v trie, nejprve byste `dog` převedli na písmena abecedy (což dá `64 6f 67`) a poté sestupovali v trie po této cestě, dokud nenajdete hodnotu. To znamená, že začnete vyhledáním kořenového hashe v ploché databázi key-value, abyste našli kořenový uzel trie. Ten je reprezentován jako pole klíčů ukazujících na jiné uzly. Použili byste hodnotu na indexu `6` jako klíč a vyhledali ji v ploché databázi klíč/hodnota, abyste získali uzel o jednu úroveň níže. Poté zvolíte index `4` pro vyhledání další hodnoty, pak index `6` a tak dále, dokud po sledování cesty: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7` nevyhledáte hodnotu uzlu a nevrátíte výsledek. + +Existuje rozdíl mezi vyhledáváním něčeho v „trie“ a v podkladové ploché databázi key-value. Obě definují uspořádání key-value, ale podkladová databáze může provést tradiční jednorázové vyhledání klíče. Vyhledávání klíče v trie vyžaduje několik podkladových vyhledávání v databázi, aby se dospělo k finální hodnotě popsané výše. Nazvěme to druhé jako `path`, abychom eliminovali nejednoznačnost. + +Operace aktualizace a mazání pro radixové trie mohou být definovány následovně: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +"Merkle" radixový strom je vytvořen propojením uzlů pomocí deterministicky generovaných kryptografických hash digestů. Toto adresování obsahu (v databázi klíč/hodnota `key == keccak256(rlp(value))`) poskytuje kryptografickou záruku integrity uložených dat. Pokud je kořenový hash daného trie veřejně známý, pak kdokoli s přístupem k podkladovým datům listů může vytvořit důkaz, že trie obsahuje danou hodnotu na konkrétní cestě tím, že poskytne hashe každého uzlu spojujícího danou hodnotu s kořenem stromu. + +Je nemožné, aby útočník poskytl důkaz o páru `(path, value)`, který neexistuje, protože kořenový haš je nakonec založen na všech haších pod ním. Jakákoli podkladová modifikace by změnila kořenový haš. Můžete si představit haš jako komprimované zobrazení strukturálních informací o datech, zajištěné ochranou před obrazy hašovací funkce. + +Atomickou jednotku radixového stromu (např. jeden hexadecimální znak nebo 4bitové binární číslo) budeme nazývat „nibble“. Při procházení cesty po jednom nibble, jak je popsáno výše, mohou uzly odkazovat na maximálně 16 potomků, ale obsahují prvek `value`. Proto je reprezentujeme jako pole o délce 17. Těmto 17prvkovým polím říkáme "větvové uzly". + +## Merkle Patricia Trie {#merkle-patricia-trees} + +Radixové trie mají jednu zásadní nevýhodu: jsou neefektivní. Pokud chcete uložit jednu vazbu `(path, value)`, kde cesta, stejně jako na Ethereu, má délku 64 znaků (počet nibblů v `bytes32`), budete potřebovat více než kilobajt dalšího prostoru pro uložení jedné úrovně na znak a každé vyhledání nebo smazání bude trvat celých 64 kroků. Patricia trie, představené níže, tento problém řeší. + +### Optimalizace {#optimization} + +Uzel v Merkle Patricia trie je jedním z následujících: + +1. `NULL` (reprezentován jako prázdný řetězec) +2. `branch` 17položkový uzel `[ v0 ...` v15, vt ]` +3. `leaf` 2položkový uzel `[ encodedPath, value ]` +4. `extension` 2položkový uzel `[ encodedPath, key ]` + +S cestami 64 znaků je nevyhnutelné, že po projití několika prvních vrstev trie se dostanete do uzlu, kde alespoň část cesty dolů neexistuje žádná divergentní cesta. Abychom se vyhnuli vytváření až 15 řídkých uzlů `NULL` podél cesty, zkrátíme sestup nastavením uzlu `extension` ve tvaru `[ encodedPath, key ]`, kde `encodedPath` obsahuje „částečnou cestu“ pro přeskočení (pomocí kompaktního kódování popsaného níže) a `key` je pro další vyhledávání v DB. + +U uzlu `leaf`, který může být označen příznakem v prvním nibble `encodedPath`, cesta kóduje všechny fragmenty cesty předchozích uzlů a hodnotu `value` můžeme vyhledat přímo. + +Tato výše uvedená optimalizace však zavádí nejednoznačnost. + +Při procházení cest po nibblech můžeme skončit s lichým počtem nibblů k procházení, ale protože všechna data jsou uložena ve formátu `bytes`. Není možné rozlišit například mezi nibblem `1` a nibbly `01` (obojí musí být uloženo jako `<01>`). Abychom specifikovali lichou délku, je částečná cesta předznačena příznakem. + +### Specifikace: Kompaktní kódování hexadecimální sekvence s volitelným terminátorem {#specification} + +Příznaky pro _lichou vs. sudou zbývající délku částečné cesty_ i pro _uzel list vs. uzel rozšíření_, jak je popsáno výše, se nacházejí v prvním nibblu částečné cesty jakéhokoli 2položkového uzlu. Výsledkem je následující: + +| hex znak | bity | částečný typ uzlu | délka cesty | +| -------- | ---- | ------------------------------------ | ----------- | +| 0 | 0000 | rozšíření | sudá | +| 1 | 0001 | rozšíření | lichá | +| 2 | 0010 | ukončující (list) | sudá | +| 3 | 0011 | ukončující (list) | lichá | + +Pro sudou zbývající délku cesty (`0` nebo `2`) bude vždy následovat další „vycpávkový“ nibble `0`. + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +Příklady: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +Zde je rozšířený kód pro získání uzlu v Merkle Patricia trie: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### Příklad Trie {#example-trie} + +Předpokládejme, že chceme trie obsahující čtyři páry cesta/hodnota `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. + +Nejprve převedeme cesty i hodnoty na `bytes`. Níže jsou skutečné bajtové reprezentace _cest_ označeny `<>`, ačkoli _hodnoty_ jsou pro snazší pochopení stále zobrazeny jako řetězce označené `''` (i ony by ve skutečnosti byly `bytes`): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +Nyní vytvoříme takový trie s následujícími páry klíč/hodnota v podkladové DB: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +Pokud jeden uzel odkazuje na jiný uzel, je zahrnuto `keccak256(rlp.encode(node))`, pokud `len(rlp.encode(node)) >= 32`, jinak `node`, kde `rlp.encode` je kódovací funkce [RLP](/developers/docs/data-structures-and-encoding/rlp). + +Všimněte si, že při aktualizaci trie je třeba uložit pár klíč/hodnota `(keccak256(x), x)` do perzistentní vyhledávací tabulky, _pokud_ má nově vytvořený uzel délku >= 32. Pokud je však uzel kratší, není třeba nic ukládat, protože funkce f(x) = x je reverzibilní. + +## Trie v Ethereu {#tries-in-ethereum} + +Všechny merkle trie v exekuční vrstvě Etherea používají Merkle Patricia Trie. + +V hlavičce bloku jsou 3 kořeny z 3 těchto trie. + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### Stavová trie {#state-trie} + +Existuje jedna globální stavová trie, která se aktualizuje pokaždé, když klient zpracuje blok. V ní je `path` vždy: `keccak256(ethereumAddress)` a `value` je vždy: `rlp(ethereumAccount)`. Konkrétně je ethereový `účet` 4položkové pole `[nonce,balance,storageRoot,codeHash]`. V tomto bodě stojí za zmínku, že tento `storageRoot` je kořenem další patricia trie: + +### Úložná trie {#storage-trie} + +V úložné trie jsou uložena _všechna_ data kontraktu. Pro každý účet existuje samostatná úložná trie. K načtení hodnot na konkrétních pozicích úložiště na dané adrese je nutná adresa úložiště, celočíselná pozice uložených dat v úložišti a ID bloku. Ty pak mohou být předány jako argumenty do `eth_getStorageAt` definovaného v JSON-RPC API, např. pro načtení dat v úložném slotu 0 pro adresu `0x295a70b2de5e3953354a6a8344e616ed314d7251`: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +Načítání dalších prvků v úložišti je o něco složitější, protože se nejprve musí vypočítat pozice v úložné trie. Pozice se vypočítá jako haš `keccak256` adresy a pozice v úložišti, obě doplněné zleva nulami na délku 32 bajtů. Například pozice pro data v úložném slotu 1 pro adresu `0x391694e7e0b0cce554cb130d723a9d27458f9298` je: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +V konzoli Geth to lze vypočítat následovně: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`path` je tedy `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. To lze nyní použít k načtení dat z úložné trie jako předtím: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +Poznámka: `storageRoot` pro ethereový účet je ve výchozím nastavení prázdný, pokud se nejedná o účet kontraktu. + +### Transakční trie {#transaction-trie} + +Pro každý blok existuje samostatná transakční trie, která opět ukládá páry `(klíč, hodnota)`. Cesta je zde: `rlp(transactionIndex)`, která představuje klíč odpovídající hodnotě určené: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +Více informací o tomto naleznete v dokumentaci k [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +### Trie účtenek {#receipts-trie} + +Každý blok má svou vlastní trie účtenek. `path` zde je: `rlp(transactionIndex)`. `transactionIndex` je jeho index v bloku, ve kterém byl zahrnut. Trie účtenek se nikdy neaktualizuje. Podobně jako transakční trie, existují aktuální a starší účtenky. Pro dotaz na konkrétní účtenku v trie účtenek je nutný index transakce v jejím bloku, datová část účtenky a typ transakce. Vrácená účtenka může být typu `Receipt`, který je definován jako zřetězení `TransactionType` a `ReceiptPayload`, nebo může být typu `LegacyReceipt`, který je definován jako `rlp([status, cumulativeGasUsed, logsBloom, logs])`. + +Více informací o tomto naleznete v dokumentaci k [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718). + +## Další čtení {#further-reading} + +- [Modifikovaný Merkle Patricia Trie – jak Ethereum ukládá stav](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Merkling v Ethereu](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Pochopení Ethereum trie](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..230dbd9f3ea --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "Serializace rekurzivního délkového prefixu (RLP)" +description: "Definice kódování RLP v exekuční vrstvě Etherea." +lang: cs +sidebarDepth: 2 +--- + +Serializace rekurzivního délkového prefixu (RLP) se hojně používá v exekučních klientech Etherea. RLP standardizuje přenos dat mezi uzly v prostorově úsporném formátu. Účelem RLP je kódovat libovolně vnořená pole binárních dat a RLP je primární metodou kódování používanou k serializaci objektů v exekuční vrstvě Etherea. Hlavním účelem RLP je kódovat strukturu; s výjimkou kladných celých čísel RLP deleguje kódování specifických datových typů (např. řetězců, čísel s plovoucí desetinnou čárkou) na protokoly vyššího řádu. Kladná celá čísla musí být reprezentována v binární formě big-endian bez úvodních nul (takže celočíselná hodnota nula je ekvivalentní prázdnému poli bajtů). Deserializovaná kladná celá čísla s úvodními nulami musí být jakýmkoli protokolem vyššího řádu používajícím RLP považována za neplatná. + +Více informací v [Ethereum yellow paper (Dodatek B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). + +Pro použití RLP ke kódování slovníku jsou dvě navrhované kanonické formy: + +- použijte `[[k1,v1],[k2,v2]...]` s klíči v lexikografickém pořadí +- použijte kódování Patricia Tree na vyšší úrovni, tak jak to dělá Ethereum + +## Definice {#definition} + +Kódovací funkce RLP přijímá položku. Položka je definována následovně: + +- řetězec (tj. pole bajtů) je položka +- seznam položek je položka +- kladné celé číslo je položka + +Například všechny následující jsou položky: + +- prázdný řetězec; +- řetězec obsahující slovo "cat"; +- seznam obsahující libovolný počet řetězců; +- a složitější datové struktury, jako je `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- číslo `100` + +Všimněte si, že v kontextu zbytku této stránky „řetězec“ znamená „určitý počet bajtů binárních dat“; nepoužívají se žádná speciální kódování a nepředpokládá se žádná znalost o obsahu řetězců (kromě toho, co vyžaduje pravidlo proti neminimálním kladným celým číslům). + +Kódování RLP je definováno následovně: + +- U kladného celého čísla se toto převede na nejkratší pole bajtů, jehož interpretace big-endian je dané celé číslo, a poté se zakóduje jako řetězec podle níže uvedených pravidel. +- Pro jediný bajt, jehož hodnota je v rozsahu `[0x00, 0x7f]` (desítkově `[0, 127]`), je tento bajt svým vlastním kódováním RLP. +- Jinak, pokud je řetězec dlouhý 0–55 bajtů, kódování RLP se skládá z jednoho bajtu s hodnotou **0x80** (des. 128) plus délka řetězce, po níž následuje samotný řetězec. Rozsah prvního bajtu je tedy `[0x80, 0xb7]` (des. `[128, 183]`). +- Pokud je řetězec delší než 55 bajtů, kódování RLP se skládá z jednoho bajtu s hodnotou **0xb7** (des. 183) plus délka délky řetězce v bajtech v binární formě, následovaná délkou řetězce a samotným řetězcem. Například řetězec dlouhý 1024 bajtů by byl zakódován jako `\xb9\x04\x00` (des. `185, 4, 0`) a za ním by následoval řetězec. Zde je `0xb9` (183 + 2 = 185) jako první bajt, po němž následují 2 bajty `0x0400` (des. 1024), které označují délku skutečného řetězce. Rozsah prvního bajtu je tedy `[0xb8, 0xbf]` (des. `[184, 191]`). +- Pokud je řetězec dlouhý 2^64 bajtů nebo více, nesmí být kódován. +- Pokud je celková datová část seznamu (tj. kombinovaná délka všech jeho položek kódovaných pomocí RLP) dlouhá 0–55 bajtů, kódování RLP se skládá z jediného bajtu s hodnotou **0xc0** plus délka datové části, po níž následuje zřetězení kódování RLP jednotlivých položek. Rozsah prvního bajtu je tedy `[0xc0, 0xf7]` (des. `[192, 247]`). +- Pokud je celková datová část seznamu delší než 55 bajtů, kódování RLP se skládá z jednoho bajtu s hodnotou **0xf7** plus délka délky datové části v bajtech v binární podobě, následovaná délkou datové části a zřetězením kódování RLP jednotlivých položek. Rozsah prvního bajtu je tedy `[0xf8, 0xff]` (des. `[248, 255]`). + +V kódu to vypadá takto: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## Příklady {#examples} + +- řetězec "dog" = [ 0x83, 'd', 'o', 'g' ] +- seznam [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- prázdný řetězec ('null') = `[ 0x80 ]` +- prázdný seznam = `[ 0xc0 ]` +- celé číslo 0 = `[ 0x80 ]` +- bajt '\\x00' = `[ 0x00 ]` +- bajt '\\x0f' = `[ 0x0f ]` +- bajty '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- [teoreticko-množinová reprezentace](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) trojky, `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- řetězec "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` + +## Dekódování RLP {#rlp-decoding} + +Podle pravidel a postupu kódování RLP je vstup pro dekódování RLP považován za pole binárních dat. Proces dekódování RLP je následující: + +1. podle prvního bajtu (tj. prefixu) vstupních dat a dekódování datového typu, délky skutečných dat a offsetu; + +2. podle typu a offsetu dat dekódujte data odpovídajícím způsobem, přičemž respektujte pravidlo minimálního kódování pro kladná celá čísla; + +3. pokračujte v dekódování zbytku vstupu; + +Pravidla pro dekódování datových typů a offsetu jsou následující: + +1. data jsou řetězec, pokud je rozsah prvního bajtu (tj. prefixu) [0x00, 0x7f], a řetězec je přesně samotný první bajt; + +2. data jsou řetězec, pokud je rozsah prvního bajtu [0x80, 0xb7] a za prvním bajtem následuje řetězec, jehož délka se rovná prvnímu bajtu mínus 0x80; + +3. data jsou řetězec, pokud je rozsah prvního bajtu [0xb8, 0xbf] a za prvním bajtem následuje délka řetězce, jejíž délka v bajtech se rovná prvnímu bajtu mínus 0xb7, a za délkou řetězce následuje samotný řetězec; + +4. data jsou seznam, pokud je rozsah prvního bajtu [0xc0, 0xf7] a za prvním bajtem následuje zřetězení kódování RLP všech položek seznamu, jejichž celková datová část se rovná prvnímu bajtu mínus 0xc0; + +5. data jsou seznam, pokud je rozsah prvního bajtu [0xf8, 0xff] a za prvním bajtem následuje celková datová část seznamu, jejíž délka se rovná prvnímu bajtu mínus 0xf7, a za celkovou datovou částí seznamu následuje zřetězení kódování RLP všech položek seznamu; + +V kódu to vypadá takto: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## Další čtení {#further-reading} + +- [RLP v Ethereu](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum pod pokličkou: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). Rekurzivní délkový prefix Etherea v ACL2. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## Související témata {#related-topics} + +- [Patricia Merkle trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..f2011db0dcd --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,150 @@ +--- +title: "Jednoduchá serializace" +description: "Vysvětlení formátu SSZ Etherea." +lang: cs +sidebarDepth: 2 +--- + +**Jednoduchá serializace (SSZ)** je metoda serializace používaná na Beacon Chainu. Nahrazuje RLP serializaci, která je používána na exekuční vrstvě a všude v rámci konsensuální vrstvy kromě protokolu pro objevování peerů. Více informací o serializaci RLP naleznete v článku [Recursive-length prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp/). SSZ je navržena tak, aby byla deterministická a také efektivně merkelizovatelná. Na SSZ můžeme pohlížet jako na dvě složky: Schéma serializace a schéma merkelizace, které je navrženo tak, aby efektivně fungovalo se serializovanou datovou strukturou. + +## Jak SSZ funguje? {#how-does-ssz-work} + +### Serializace {#serialization} + +SSZ je schéma serializace, které není samo o sobě popisné - spíše spoléhá na schéma, které musí být předem známo. Cílem SSZ serializace je reprezentovat objekty libovolné složitosti jako řetězce bajtů. Tento proces je velmi jednoduchý pro "základní typy". Element je jednoduše převeden na hexadecimální bajty. Mezi základní typy patří: + +- celá čísla bez znaménka +- booleovské hodnoty + +Pro složité "kompozitní" typy je serializace složitější, protože kompozitní typ obsahuje více prvků, které mohou mít různé typy nebo různé velikosti, nebo obojí. V případech, kdy mají všechny tyto objekty pevnou délku (tj. velikost prvků bude vždy konstantní bez ohledu na jejich skutečné hodnoty), je serializace jednoduše konverzí každého prvku ve složeném typu, seřazeného do little-endian bajtových řetězců. Tyto bajtové řetězce jsou spojeny dohromady. Serializovaný objekt má bytelistovou reprezentaci prvků s pevnou délkou ve stejném pořadí, v jakém se objevují v deserializovaném objektu. + +Pro typy s proměnlivou délkou se skutečná data nahrazují hodnotou "offsetu" na pozici toho prvku v serializovaném objektu. Skutečná data se přidávají do zásobníku na konci serializovaného objektu. Hodnota offsetu je indexem pro začátek skutečných dat v zásobníku, což funguje jako ukazatel na příslušné bajty. + +Následující příklad ilustruje, jak funguje offsetování pro kontejner s prvky s pevnou i proměnlivou délkou: + +```Rust + + struct Dummy { + + number1: u64, + number2: u64, + vector: Vec, + number3: u64 + } + + dummy = Dummy{ + + number1: 37, + number2: 55, + vector: vec![1,2,3,4], + number3: 22, + } + + serialized = ssz.serialize(dummy) + +``` + +`serialized` by mělo následující strukturu (zde pouze doplněno na 4 bity, ve skutečnosti doplněno na 32 bitů a pro přehlednost je zachována reprezentace `int`): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + number1 number2 posun pro number 3 hodnota pro + vektor vektor + +``` + +pro přehlednost je rozdělíme do řádků: + +``` +[ + 37, 0, 0, 0, # kódování `number1` v pořadí little-endian. + 55, 0, 0, 0, # kódování `number2` v pořadí little-endian. + 16, 0, 0, 0, # „Posun“, který udává, kde začíná hodnota `vector` (little-endian 16). + 22, 0, 0, 0, # kódování `number3` v pořadí little-endian. + 1, 2, 3, 4, # Skutečné hodnoty ve `vector`. +] +``` + +Toto je stále zjednodušení - celá čísla a nuly ve schématech výše by ve skutečnosti byly uloženy bytelisty, jako je tento: + +``` +[ + 10100101000000000000000000000000 # kódování `number1` v pořadí little-endian + 10110111000000000000000000000000 # kódování `number2` v pořadí little-endian. + 10010000000000000000000000000000 # „Posun“, který udává, kde začíná hodnota `vector` (little-endian 16). + 10010110000000000000000000000000 # kódování `number3` v pořadí little-endian. + 10000001100000101000001110000100 # Skutečná hodnota pole `bytes`. +] +``` + +Takže skutečné hodnoty pro typy s proměnlivou délkou jsou uloženy v zásobníku na konci serializovaného objektu, přičemž jejich offsety jsou uloženy na správných pozicích v uspořádaném seznamu polí. + +Existují také některé speciální případy, které vyžadují specifické zacházení, například typ `BitList`, který vyžaduje přidání délkového limitu během serializace a jeho odstranění během deserializace. Veškeré podrobnosti jsou k dispozici ve [specifikaci SSZ](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md). + +### Deserializace {#deserialization} + +K deserializaci tohoto objektu je zapotřebí schéma. Schéma definuje přesné uspořádání serializovaných dat tak, aby každý konkrétní prvek mohl být deserializován z blobu bajtů do nějakého smysluplného objektu s prvky majícími správný typ, hodnotu, velikost a pozici. Je to právě schéma, které říká deserializátoru, které hodnoty jsou skutečné hodnoty a které jsou offsety. Všechny názvy polí zmizí, když je objekt serializován, ale při deserializaci se podle schématu znovu vytvoří. + +Pro interaktivní vysvětlení se podívejte na [ssz.dev](https://www.ssz.dev/overview). + +## Merkleizace {#merkleization} + +Tento SSZ serializovaný objekt pak může být merkelizován - to znamená transformován do Merkleova stromu reprezentujícího stejná data. Nejprve se určí počet 32bajtových bloků v serializovaném objektu. Tyto bloky tvoří „listy“ stromu. Celkový počet listů musí být mocnina dvou, aby hašování listů nakonec vytvořilo jediný hašový kořen stromu. Pokud tomu tak přirozeně není, jsou přidány další listy obsahující 32 bajtů nul. Schématicky: + +``` + kořen hašového stromu + / \ + / \ + / \ + / \ + haš listů haš listů + 1 a 2 3 a 4 + / \ / \ + / \ / \ + / \ / \ + list1 list2 list3 list4 +``` + +Existují také případy, kdy se listy stromu přirozeně nerozdělují rovnoměrně, jako tomu bylo v předchozím příkladu. Například list 4 by mohl být kontejner s více prvky, které vyžadují přidání další "hloubky" do Merkle tree, čímž se vytvoří nerovnoměrný strom. + +Místo toho, abychom tyto prvky stromu označovali jako list X, uzel X atd., můžeme jim přiřadit zobecněné indexy, počínaje kořenem = 1 a číslováním zleva doprava na každé úrovni. Toto je zobecněný index, který jsme vysvětlili výše. Každý prvek v serializovaném seznamu má zobecněný index rovný `2**depth + idx`, kde idx je jeho pozice s indexem nula v serializovaném objektu a hloubka je počet úrovní v Merkle tree, který lze určit jako logaritmus počtu prvků (listů) při základu 2. + +## Zobecněné indexy {#generalized-indices} + +Zobecněný index je celé číslo, které představuje uzel v binárním Merkle tree, kde každý uzel má zobecněný index `2 ** depth + index in row`. + +``` + 1 --hloubka = 0 2**0 + 0 = 1 + 2 3 --hloubka = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --hloubka = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +Toto zobrazení poskytuje index uzlu pro každý datový prvek v Merkletree. + +## Multiproofy {#multiproofs} + +Poskytnutí seznamu zobecněných indexů představujících konkrétní prvek nám umožňuje jej ověřit vůči hašovému kořenovému stromu. Tento kořen je naším přijatým zobrazením reality. Jakákoli data, která nám jsou poskytnuta, mohou být ověřena vůči této realitě vložením do správného místa v Merkle tree (určeného jeho zobecněným indexem) a pozorováním, zda kořen zůstává konstantní. Ve specifikaci [zde](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) jsou funkce, které ukazují, jak vypočítat minimální sadu uzlů potřebnou k ověření obsahu konkrétní sady zobecněných indexů. + +Například k ověření dat na indexu 9 v níže uvedeném stromu potřebujeme haš dat na indexech 8, 9, 5, 3, 1. +Haš (8,9) by měl být roven haši (4), který se hašuje s 5 a vytváří 2, který se hašuje s 3 a vytváří kořen stromu 1. Pokud by byla poskytnuta nesprávná data pro 9, kořen by se změnil – to bychom zjistili a ověření větve by selhalo. + +``` +* = data potřebná k vygenerování důkazu + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## Další čtení {#further-reading} + +- [Vylepšení Etherea: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Vylepšení Etherea: Merkleizace](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [Implementace SSZ](https://github.com/ethereum/consensus-specs/issues/2138) +- [Kalkulačka SSZ](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md new file mode 100644 index 00000000000..42df8413a93 --- /dev/null +++ b/public/content/translations/cs/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -0,0 +1,195 @@ +--- +title: "Definice tajného úložiště web3" +description: "Formální definice pro tajné úložiště web3" +lang: cs +sidebarDepth: 2 +--- + +Aby vaše aplikace fungovala na síti Ethereum, můžete použít objekt web3 poskytovaný knihovnou web3.js. Na pozadí komunikuje s místním uzlem prostřednictvím volání RPC. [web3](https://github.com/ethereum/web3.js/) funguje s jakýmkoli uzlem Ethereum, který zpřístupňuje vrstvu RPC. + +`web3` obsahuje objekt `eth` – web3.eth. + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** výsledek + * [ 'web3', 3 ] soubor s klíčem web3 (v3) + * [ 'ethersale', undefined ] soubor s klíčem Ethersale + * null neplatný soubor s klíčem + */ +``` + +Tento dokument popisuje **verzi 3** definice tajného úložiště Web3. + +## Definice {#definition} + +Vlastní kódování a dekódování souboru zůstává z velké části nezměněno oproti verzi 1, s tím rozdílem, že kryptoalgoritmus již není pevně nastaven na AES-128-CBC (minimálním požadavkem je nyní AES-128-CTR). Většina významů/algoritmů je podobná verzi 1, kromě `mac`, který je dán jako SHA3 (keccak-256) zřetězení druhých 16 bajtů zleva odvozeného klíče společně s úplným `ciphertextem`. + +Soubory s tajným klíčem jsou uloženy přímo v `~/.web3/keystore` (pro systémy podobné Unixu) a `~/AppData/Web3/keystore` (pro Windows). Mohou být pojmenovány jakkoli, ale dobrou konvencí je `.json`, kde `` je 128bitový identifikátor UUID přiřazený tajnému klíči (proxy chránící soukromí pro adresu tajného klíče). + +Všechny takové soubory mají přidružené heslo. Chcete-li odvodit tajný klíč daného souboru `.json`, nejprve odvoďte šifrovací klíč souboru; to se provede tak, že vezmete heslo souboru a předáte ho funkci pro odvození klíče, jak je popsáno v klíči `kdf`. Statické a dynamické parametry závislé na KDF pro funkci KDF jsou popsány v klíči `kdfparams`. + +PBKDF2 musí být podporován všemi minimálně vyhovujícími implementacemi, označeno jako: + +- `kdf`: `pbkdf2` + +Pro PBKDF2 parametry kdfparams zahrnují: + +- `prf`: Musí být `hmac-sha256` (může být v budoucnu rozšířen); +- `c`: počet iterací; +- `salt`: sůl předaná do PBKDF; +- `dklen`: délka odvozeného klíče. Musí být >= 32. + +Jakmile byl klíč souboru odvozen, měl by být ověřen prostřednictvím odvození MAC. MAC by se měl vypočítat jako haš SHA3 (keccak-256) bajtového pole vytvořeného zřetězením druhých 16 bajtů zleva odvozeného klíče s obsahem klíče `ciphertext`, tj.: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(kde `++` je operátor zřetězení) + +Tato hodnota by se měla porovnat s obsahem klíče `mac`; pokud se liší, mělo by se vyžádat alternativní heslo (nebo operace zrušena). + +Po ověření klíče souboru může být šifrovaný text (klíč `ciphertext` v souboru) dešifrován pomocí algoritmu symetrického šifrování specifikovaného klíčem `cipher` a parametrizovaného pomocí klíče `cipherparams`. Pokud se velikost odvozeného klíče a velikost klíče algoritmu neshodují, měly by se jako klíč k algoritmu použít nejvíce pravé bajty odvozeného klíče, doplněné nulami. + +Všechny minimálně vyhovující implementace musí podporovat algoritmus AES-128-CTR, označený jako: + +- `cipher: aes-128-ctr` + +Tato šifra přebírá následující parametry, uvedené jako klíče ke klíči cipherparams: + +- `iv`: 128bitový inicializační vektor pro šifru. + +Klíčem pro šifru je 16 nejvíce levých bajtů odvozeného klíče, tj. `DK[0..15]` + +Vytvoření/zašifrování tajného klíče by mělo být v podstatě opakem těchto pokynů. Ujistěte se, že `uuid`, `salt` a `iv` jsou skutečně náhodné. + +Kromě pole `version`, které by mělo fungovat jako "tvrdý" identifikátor verze, mohou implementace také používat `minorversion` ke sledování menších změn formátu, které nenaruší zpětnou kompatibilitu. + +## Testovací vektory {#test-vectors} + +Podrobnosti: + +- `Adresa`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `Heslo`: `testpassword` +- `Tajný klíč`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +Testovací vektor používající `AES-128-CTR` a `PBKDF2-SHA-256`: + +Obsah souboru `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json`: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Mezivýsledky**: + +`Odvozený klíč`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` +`Tělo MAC`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` +`MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` +`Šifrovací klíč`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +Testovací vektor používající AES-128-CTR a Scrypt: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Mezivýsledky**: + +`Odvozený klíč`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` +`Tělo MAC`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` +`MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` +`Šifrovací klíč`: `7446f59ecc301d2d79bc3302650d8a5c` + +## Změny oproti verzi 1 {#alterations-from-v2} + +Tato verze opravuje několik nesrovnalostí s verzí 1 publikovanou [zde](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst). Stručně řečeno se jedná o: + +- Použití velkých a malých písmen je neopodstatněné a nekonzistentní (scrypt malými písmeny, Kdf s různou velikostí písmen, MAC velkými písmeny). +- Adresa je zbytečná a ohrožuje soukromí. +- `Salt` je ze své podstaty parametrem funkce pro odvození klíče a zaslouží si být s ní spojena, nikoli s kryptem obecně. +- _SaltLen_ je zbytečné (stačí jej odvodit ze Salt). +- Funkce pro odvození klíče je dána, ale kryptoalgoritmus je pevně specifikován. +- `Version` je ze své podstaty číselná, ale je to řetězec (strukturované verzování by bylo možné s řetězcem, ale lze to považovat za nadbytečné pro formát konfiguračního souboru, který se mění jen zřídka). +- `KDF` a `cipher` jsou teoreticky sourozenecké koncepty, ale jsou organizovány odlišně. +- `MAC` se vypočítává z datového bloku, který ignoruje prázdné znaky (!) + +Ve formátu byly provedeny změny tak, aby vznikl následující soubor, který je funkčně ekvivalentní příkladu uvedenému na dříve odkazované stránce: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## Změny oproti verzi 2 {#alterations-from-v2} + +Verze 2 byla raná implementace v C++ s řadou chyb. Všechny základní věci v ní zůstávají beze změny. diff --git a/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..c94cfec2cd8 --- /dev/null +++ b/public/content/translations/cs/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,219 @@ +--- +title: "Osvědčené postupy návrhu decentralizovaných burz (DEX)" +description: "Průvodce vysvětlující rozhodnutí o návrhu UX/UI pro směnu tokenů." +lang: cs +--- + +Od spuštění Uniswapu v roce 2018 byly spuštěny stovky decentralizovaných burz na desítkách různých řetězců. +Mnohé z nich zavedly nové prvky nebo přidaly vlastní vylepšení, ale rozhraní zůstalo obecně stejné. + +Jedním z důvodů je [Jakobův zákon](https://lawsofux.com/jakobs-law/): + +> Uživatelé tráví většinu svého času na jiných stránkách. To znamená, že uživatelé dávají přednost tomu, aby vaše stránky fungovaly stejně jako všechny ostatní stránky, které již znají. + +Díky prvním inovátorům, jako jsou Uniswap, Pancakeswap a Sushiswap, mají uživatelé DeFi kolektivní představu o tom, jak DEX vypadá. +Z tohoto důvodu se nyní objevuje něco jako „osvědčený postup“. Stále častěji vidíme, že se rozhodnutí o designu napříč weby standardizují. Vývoj DEX můžete vnímat jako obrovský příklad testování v reálném čase. Věci, které fungovaly, zůstaly, věci, které ne, byly zahozeny. Stále je zde prostor pro osobitost, ale existují určité standardy, kterým by měla DEX vyhovovat. + +Tento článek je shrnutím: + +- co zahrnout +- jak to udělat co nejpoužitelnější +- hlavní způsoby přizpůsobení designu + +Všechny příklady drátěných modelů (wireframes) byly vytvořeny speciálně pro tento článek, ačkoli všechny vycházejí ze skutečných projektů. + +Sada pro Figmu je také zahrnuta na konci – klidně ji použijte a zrychlete si tak tvorbu vlastních drátěných modelů! + +## Základní anatomie DEX {#basic-anatomy-of-a-dex} + +Uživatelské rozhraní (UI) obecně obsahuje tři prvky: + +1. Hlavní formulář +2. Tlačítko +3. Panel s podrobnostmi + +![Obecné UI burzy DEX zobrazující tři hlavní prvky](./1.png) + +## Varianty {#variations} + +To bude v tomto článku běžné téma, ale existují různé způsoby, jak mohou být tyto prvky uspořádány. „Panel podrobností“ může být: + +- Nad tlačítkem +- Pod tlačítkem +- Skrytý v rozbalovacím panelu +- A/nebo v modálním okně „náhledu“ + +Pozn. Modální okno „náhledu“ je volitelné, ale pokud v hlavním uživatelském rozhraní zobrazujete jen velmi málo podrobností, stává se nezbytným. + +## Struktura hlavního formuláře {#structure-of-the-main-form} + +Toto je pole, kde si skutečně vybíráte, který token chcete směnit. Komponenta se skládá ze vstupního pole a malého tlačítka v jednom řádku. + +Burzy DEX obvykle zobrazují další podrobnosti v jednom řádku nad a v jednom řádku pod, i když to lze nakonfigurovat i jinak. + +![Vstupní řádek s řádkem podrobností nad a pod](./2.png) + +## Varianty {#variations2} + +Jsou zde uvedeny dvě varianty uživatelského rozhraní; jedna bez ohraničení, která vytváří velmi otevřený design, a druhá, kde má vstupní řádek ohraničení, což vytváří zaměření na tento prvek. + +![Dvě varianty UI hlavního formuláře](./3.png) + +Tato základní struktura umožňuje v návrhu zobrazit **čtyři klíčové informace**: jednu v každém rohu. Pokud existuje pouze jeden horní/dolní řádek, pak jsou k dispozici pouze dvě místa. + +Během vývoje DeFi se sem zařadilo mnoho různých věcí. + +## Klíčové informace, které je třeba zahrnout {#key-info-to-include} + +- Zůstatek v peněžence +- Tlačítko Max +- Fiatový ekvivalent +- Dopad na cenu u „obdržené“ částky + +V počátcích DeFi fiatový ekvivalent často chyběl. Pokud vytváříte jakýkoli projekt Web3, je nezbytné, aby byl zobrazen fiatový ekvivalent. Uživatelé stále přemýšlejí v místních měnách, takže aby to odpovídalo jejich mentálním modelům z reálného světa, mělo by to být zahrnuto. + +Ve druhém poli (v tom, kde si vybíráte token, na který směňujete) můžete také uvést dopad na cenu vedle částky ve fiat měně, a to výpočtem rozdílu mezi vstupní částkou a odhadovanou výstupní částkou. Je to poměrně užitečný detail, který je dobré zahrnout. + +Procentuální tlačítka (např. 25 %, 50 %, 75 %) mohou být užitečnou funkcí, ale zabírají více místa, přidávají více výzev k akci a zvyšují mentální zátěž. To samé platí pro procentuální posuvníky. Některá z těchto rozhodnutí ohledně UI budou záviset na vaší značce a typu uživatele. + +Další podrobnosti mohou být zobrazeny pod hlavním formulářem. Protože je tento typ informací určen především pro profesionální uživatele, dává smysl buď: + +- udržovat ho co nejminimálnější, nebo; +- skrýt ho do rozbalovacího panelu + +![Podrobnosti zobrazené v rozích hlavního formuláře](./4.png) + +## Další informace k zahrnutí {#extra-info-to-include} + +- Cenu tokenu +- Skluz +- Minimální obdržená částka +- Očekávaný výstup +- Dopad na cenu +- Odhad nákladů na gas +- Další poplatky +- Směrování příkazu + +Některé z těchto údajů by mohly být volitelné. + +Směrování příkazů je zajímavé, ale pro většinu uživatelů nepředstavuje velký rozdíl. + +Některé další podrobnosti pouze uvádějí totéž různými způsoby. Například „minimální obdržená částka“ a „skluz“ jsou dvě strany téže mince. Pokud máte skluz nastavený na 1 %, pak minimální částka, kterou můžete očekávat, se rovná očekávanému výstupu - 1 %. Některá UI zobrazují očekávanou částku, minimální částku a skluz… Což je užitečné, ale možná až přehnané. + +Většina uživatelů stejně ponechá výchozí nastavení skluzu. + +„Dopad na cenu“ se často zobrazuje v závorkách vedle fiatového ekvivalentu v poli „Do“. Je to skvělý UX detail, který lze přidat, ale pokud je zobrazen zde, je opravdu nutné ho znovu zobrazovat níže? A pak znovu na obrazovce náhledu? + +Mnoho uživatelů (zejména těch, kteří směňují malé částky) se o tyto podrobnosti nebude starat; jednoduše zadají číslo a stisknou tlačítko pro směnu. + +![Některé podrobnosti ukazují stejnou věc](./5.png) + +Jaké podrobnosti přesně zobrazíte, bude záviset na vašem publiku a na tom, jaký dojem má aplikace budit. + +Pokud do panelu s podrobnostmi zahrnete toleranci skluzu, měli byste ji také umožnit upravovat přímo odtud. Toto je dobrý příklad „urychlovače“; šikovný trik v UX, který může zrychlit postupy zkušených uživatelů, aniž by to ovlivnilo obecnou použitelnost aplikace. + +![Skluz lze ovládat z panelu podrobností](./6.png) + +Je dobré se pečlivě zamyslet nejen nad jednou konkrétní informací na jedné obrazovce, ale nad celým postupem: zadání čísel v hlavním formuláři → kontrola podrobností → kliknutí na obrazovku náhledu (pokud ji máte). +Měl by být panel s podrobnostmi viditelný po celou dobu, nebo musí uživatel kliknout, aby ho rozbalil? +Měli byste vytvářet tření přidáním obrazovky náhledu? To donutí uživatele zpomalit a zvážit svůj obchod, což může být užitečné. Ale chtějí vidět všechny stejné informace znovu? Co je pro ně v tuto chvíli nejužitečnější? + +## Možnosti návrhu {#design-options} + +Jak již bylo zmíněno, mnoho z toho závisí na vašem osobním stylu +Kdo je váš uživatel? +Jaká je vaše značka? +Chcete „profesionální“ rozhraní, které zobrazuje každý detail, nebo chcete být minimalističtí? +I když se zaměřujete na profesionální uživatele, kteří chtějí všechny možné informace, měli byste si pamatovat moudrá slova Alana Coopera: + +> Bez ohledu na to, jak krásné a skvělé je vaše rozhraní, bylo by lepší, kdyby ho bylo méně. + +### Struktura {#structure} + +- tokeny vlevo, nebo tokeny vpravo +- 2 nebo 3 řádky +- podrobnosti nad nebo pod tlačítkem +- podrobnosti rozbalené, sbalené nebo nezobrazené + +### Styl komponenty {#component-style} + +- prázdný +- s obrysem +- vyplněný + +Z čistě UX hlediska na stylu UI záleží méně, než si myslíte. Vizuální trendy přicházejí a odcházejí v cyklech a mnoho preferencí je subjektivních. + +Nejjednodušší způsob, jak to pochopit – a přemýšlet o různých konfiguracích – je podívat se na několik příkladů a pak si sami zaexperimentovat. + +Přiložená sada pro Figmu obsahuje prázdné, obrysové a vyplněné komponenty. + +Podívejte se na níže uvedené příklady, abyste viděli různé způsoby, jak to všechno můžete složit dohromady: + +![3 řádky ve vyplněném stylu](./7.png) + +![3 řádky ve stylu s obrysem](./8.png) + +![2 řádky v prázdném stylu](./9.png) + +![3 řádky ve stylu s obrysem, s panelem podrobností](./10.png) + +![3 řádky se vstupním řádkem ve stylu s obrysem](./11.png) + +![2 řádky ve vyplněném stylu](./12.png) + +## Ale na kterou stranu by měl token jít? {#but-which-side-should-the-token-go-on} + +Podstatné je, že to na použitelnost pravděpodobně nemá velký vliv. Existuje však několik věcí, které je třeba mít na paměti a které vás mohou přiklonit na jednu nebo druhou stranu. + +Je mírně zajímavé sledovat, jak se móda s časem mění. Uniswap měl původně token vlevo, ale od té doby ho přesunul doprava. Sushiswap také provedl tuto změnu během vylepšení designu. Většina, ale ne všechny protokoly následovaly. + +Finanční konvence tradičně umisťuje symbol měny před číslo, např. $50, €50, £50, ale my _říkáme_ 50 dolarů, 50 eur, 50 liber. + +Pro běžného uživatele – zejména pro toho, kdo čte zleva doprava, shora dolů – je token vpravo pravděpodobně přirozenější. + +![UI s tokeny vlevo](./13.png) + +Umístění tokenu vlevo a všech čísel vpravo vypadá příjemně symetricky, což je plus, ale toto uspořádání má i další nevýhodu. + +Zákon blízkosti říká, že prvky, které jsou blízko u sebe, jsou vnímány jako související. Proto chceme umisťovat související položky vedle sebe. Zůstatek tokenu přímo souvisí se samotným tokenem a změní se vždy, když je vybrán nový token. Proto dává o něco větší smysl, aby byl zůstatek tokenu vedle tlačítka pro výběr tokenu. Mohl by být přesunut pod token, ale to narušuje symetrii rozvržení. + +Nakonec mají obě možnosti svá plusy a mínusy, ale je zajímavé, jak se zdá, že trend směřuje k tokenu napravo. + +## Chování tlačítka {#button-behavior} + +Nemějte samostatné tlačítko pro Schválit. Také nemějte samostatné kliknutí pro Schválit. Uživatel chce směnit, takže na tlačítku stačí uvést „Směnit“ a jako první krok zahájit schválení. Modální okno může zobrazovat pokrok pomocí krokování nebo jednoduchého oznámení „transakce 1 ze 2 – schvalování“. + +![UI se samostatnými tlačítky pro schválení a směnu](./14.png) + +![UI s jedním tlačítkem s nápisem „Schválit“](./15.png) + +### Tlačítko jako kontextová nápověda {#button-as-contextual-help} + +Tlačítko může sloužit dvojímu účelu jako upozornění! + +Je to vlastně poměrně neobvyklý designový vzor mimo Web3, ale v něm se stal standardem. Je to dobrá inovace, protože šetří místo a udržuje pozornost. + +Pokud je hlavní akce – SMĚNIT – nedostupná z důvodu chyby, důvod lze vysvětlit pomocí tlačítka, např.: + +- přepnout síť +- připojit peněženku +- různé chyby + +Tlačítko může být také **přiřazeno k akci**, která má být provedena. Například pokud uživatel nemůže provést směnu, protože je na špatné síti, na tlačítku by mělo být uvedeno „Přepnout na Ethereum“ a po kliknutí na tlačítko by se síť měla přepnout na Ethereum. To výrazně zrychluje postup uživatele. + +![Klíčové akce iniciované z hlavní výzvy k akci (CTA)](./16.png) + +![Chybová zpráva zobrazená v hlavní výzvě k akci (CTA)](./17.png) + +## Vytvořte si vlastní pomocí tohoto souboru Figma {#build-your-own-with-this-figma-file} + +Díky tvrdé práci několika protokolů se design DEX hodně zlepšil. Víme, jaké informace uživatel potřebuje, jak bychom je měli zobrazit a jak zajistit, aby byl postup co nejplynulejší. +Doufejme, že tento článek poskytuje solidní přehled principů UX. + +Pokud chcete experimentovat, neváhejte použít sadu drátěných modelů pro Figma. Je co nejjednodušší, ale má dostatečnou flexibilitu k tomu, aby bylo možné základní strukturu sestavit různými způsoby. + +[Sada drátěných modelů pro Figma](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +DeFi se bude i nadále vyvíjet a vždy je co zlepšovat. + +Hodně štěstí! diff --git a/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..3c6b86124cf --- /dev/null +++ b/public/content/translations/cs/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: "7 heuristik pro návrh rozhraní Web3" +description: "Principy pro zlepšení použitelnosti Web3" +lang: cs +--- + +Heuristiky použitelnosti jsou obecná „empirická pravidla“, která můžete použít k měření použitelnosti vašich stránek. +Těchto 7 heuristik je speciálně přizpůsobeno pro Web3 a měly by se používat společně s [deseti obecnými principy pro návrh interakce](https://www.nngroup.com/articles/ten-usability-heuristics/) od Jakoba Nielsena. + +## Sedm heuristik použitelnosti pro Web3 {#seven-usability-heuristics-for-web3} + +1. Zpětná vazba následuje po akci +2. Bezpečnost a důvěra +3. Nejdůležitější informace jsou zřejmé +4. Srozumitelná terminologie +5. Akce jsou co nejkratší +6. Síťová připojení jsou viditelná a flexibilní +7. Ovládání z aplikace, nikoli z peněženky + +## Definice a příklady {#definitions-and-examples} + +### 1. Zpětná vazba následuje po akci {#feedback-follows-action} + +**Mělo by být zřejmé, kdy se něco stalo nebo se děje.** + +Uživatelé se rozhodují o svých dalších krocích na základě výsledku svých předchozích kroků. Proto je nezbytné, aby byli stále informováni o stavu systému. To je důležité zejména ve Web3, protože transakcím může někdy chvíli trvat, než se zapíší do blockchainu. Pokud není k dispozici žádná zpětná vazba, která by je informovala, aby počkali, uživatelé si nejsou jisti, zda se něco stalo. + +**Tipy:** + +- Informujte uživatele prostřednictvím zpráv, oznámení a dalších upozornění. +- Srozumitelně sdělujte čekací doby. +- Pokud bude akce trvat déle než několik sekund, uklidněte uživatele časovačem nebo animací, aby měli pocit, že se něco děje. +- Pokud má proces více kroků, zobrazte každý krok. + +**Příklad:** +Zobrazení každého kroku transakce pomáhá uživatelům vědět, kde se v procesu nacházejí. Vhodné ikony informují uživatele o stavu jejich akcí. + +![Informování uživatele o každém kroku při směně tokenů](./Image1.png) + +### 2. Bezpečnost a důvěra jsou integrovány {#security-and-trust-are-backed-in} + +Bezpečnost by měla být prioritou a to by mělo být uživateli zdůrazněno. +Lidem velmi záleží na jejich datech. Bezpečnost je pro uživatele často primárním zájmem, proto by se na ni mělo myslet na všech úrovních návrhu. Vždy byste se měli snažit získat důvěru svých uživatelů, ale způsob, jakým to děláte, se může u různých aplikací lišit. Nemělo by se na to myslet dodatečně, ale mělo by to být vědomě navrženo v celém rozsahu. Budujte důvěru v rámci celé uživatelské zkušenosti, včetně sociálních kanálů a dokumentace, a také konečného uživatelského rozhraní. Věci jako úroveň decentralizace, stav multi-sig pokladnice a to, zda je tým „doxxed“ (veřejně známý), to vše ovlivňuje důvěru uživatelů. + +**Tipy:** + +- Hrdě uvádějte své audity +- Získejte několik auditů +- Propagujte všechny bezpečnostní funkce, které jste navrhli +- Zvýrazněte možná rizika, včetně souvisejících integrací +- Sdělujte složitost strategií +- Zvažte problémy mimo uživatelské rozhraní, které by mohly ovlivnit vnímání bezpečnosti vašimi uživateli + +**Příklad:** +Uveďte své audity v zápatí na viditelném místě. + +![Odkazy na audity v zápatí webu](./Image2.png) + +### 3. Nejdůležitější informace jsou zřejmé {#the-most-important-info-is-obvious} + +U složitých systémů zobrazujte pouze nejrelevantnější data. Určete, co je nejdůležitější, a upřednostněte zobrazení těchto informací. +Příliš mnoho informací je zahlcující a uživatelé se při rozhodování obvykle soustředí na jednu informaci. V DeFi to bude pravděpodobně RPSN u výnosových aplikací a LTV u aplikací pro půjčování. + +**Tipy:** + +- Uživatelský průzkum odhalí nejdůležitější metriku +- Klíčové informace udělejte velké a ostatní detaily malé a nenápadné +- Lidé nečtou, ale prolétávají text očima; zajistěte, aby byl váš design snadno přehledný + +**Příklad:** Velké, plně barevné tokeny lze při rychlém procházení snadno najít. RPSN je velká a zvýrazněná doplňkovou barvou. + +![Token a RPSN lze snadno najít](./Image3.png) + +### 4. Jasná terminologie {#clear-terminology} + +Terminologie by měla být srozumitelná a vhodná. +Technický žargon může být obrovskou překážkou, protože vyžaduje vytvoření zcela nového mentálního modelu. Uživatelé si nedokážou spojit design se slovy, frázemi a koncepty, které již znají. Všechno se zdá matoucí a neznámé a je zde strmá křivka učení, než se vůbec pokusí aplikaci použít. Uživatel může přijít k DeFi s tím, že si chce ušetřit nějaké peníze, a najde: těžbu, farming, stakování, emise, úplatky, trezory, skříňky, veTokeny, vesting, epochy, decentralizované algoritmy, likviditu vlastněnou protokolem… +Snažte se používat jednoduché termíny, kterým porozumí co nejširší skupina lidí. Nevymýšlejte zcela nové termíny jen pro svůj projekt. + +**Tipy:** + +- Používejte jednoduchou a konzistentní terminologii +- Co nejvíce používejte stávající jazyk +- Nevymýšlejte si vlastní termíny +- Dodržujte konvence tak, jak se objevují +- Co nejvíce vzdělávejte uživatele + +**Příklad:** +„Vaše odměny“ je široce srozumitelný, neutrální termín; nikoliv nové slovo vymyšlené pro tento projekt. Odměny jsou denominovány v USD, aby odpovídaly mentálním modelům reálného světa, i když samotné odměny jsou v jiném tokenu. + +![Odměny v tokenech, zobrazené v amerických dolarech](./Image4.png) + +### 5. Akce jsou co nejkratší {#actions-are-as-short-as-possible} + +Zrychlete interakce uživatele seskupením dílčích akcí. +To lze provést na úrovni chytrého kontraktu i na úrovni uživatelského rozhraní. Uživatel by se neměl muset přesouvat z jedné části systému do druhé – nebo systém zcela opouštět – aby dokončil běžnou akci. + +**Tipy:** + +- Kombinujte „Schválit“ s jinými akcemi, kde je to možné +- Seskupte kroky podepisování co nejblíže k sobě + +**Příklad:** Kombinace „přidat likviditu“ a „stakovat“ je jednoduchým příkladem urychlovače, který uživateli šetří čas i palivo. + +![Modální okno zobrazující přepínač pro zkombinování akcí vkladu a stakování](./Image5.png) + +### 6. Síťová připojení jsou viditelná a flexibilní {#network-connections-are-visible-and-flexible} + +Informujte uživatele o tom, ke které síti je připojen, a poskytněte jasné zkratky pro změnu sítě. +To je důležité zejména u multichain aplikací. Hlavní funkce aplikace by měly být stále viditelné, i když je odpojena nebo připojena k nepodporované síti. + +**Tipy:** + +- Při odpojení zobrazte co nejvíce z aplikace +- Zobrazte, ke které síti je uživatel aktuálně připojen +- Nenuťte uživatele chodit do peněženky, aby změnil síť +- Pokud aplikace vyžaduje, aby uživatel přepnul síť, vyzvěte k akci z hlavní výzvy k akci +- Pokud aplikace obsahuje trhy nebo trezory pro více sítí, jasně uveďte, kterou sadu si uživatel právě prohlíží + +**Příklad:** Ukažte uživateli, ke které síti je připojen, a umožněte mu ji změnit v panelu aplikace. + +![Rozbalovací tlačítko zobrazující připojenou síť](./Image6.png) + +### 7. Ovládání z aplikace, nikoli z peněženky {#control-from-the-app-not-the-wallet} + +Uživatelské rozhraní by mělo uživateli sdělit vše, co potřebuje vědět, a dát mu kontrolu nad vším, co potřebuje udělat. +Ve Web3 existují akce, které provádíte v uživatelském rozhraní, a akce, které provádíte v peněžence. Obecně platí, že akci zahájíte v uživatelském rozhraní a poté ji potvrdíte v peněžence. Uživatelé se mohou cítit nepříjemně, pokud tyto dvě části nejsou pečlivě integrovány. + +**Tipy:** + +- Informujte o stavu systému prostřednictvím zpětné vazby v uživatelském rozhraní +- Veďte záznamy o jejich historii +- Poskytněte odkazy na prohlížeče bloků pro staré transakce +- Poskytněte zkratky pro změnu sítí. + +**Příklad:** Nenápadný kontejner ukazuje uživateli, jaké relevantní tokeny má ve své peněžence, a hlavní výzva k akci poskytuje zkratku ke změně sítě. + +![Hlavní výzva k akci vyzývá uživatele k přepnutí sítě](./Image7.png) diff --git a/public/content/translations/cs/developers/docs/design-and-ux/index.md b/public/content/translations/cs/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..941351f36c8 --- /dev/null +++ b/public/content/translations/cs/developers/docs/design-and-ux/index.md @@ -0,0 +1,86 @@ +--- +title: Design a UX ve web3 +description: "Úvod do UX designu a výzkumu ve web3 prostoru a v ekosystému Etherea" +lang: cs +--- + +Jste v navrhování pro Ethereum nováčci? Pak jste na správném místě. Komunita Etherea vytvořila zdroje, které vás seznámí se základy designu a výzkumu v prostředí web3. Dozvíte se zde se o klíčových konceptech, které se mohou lišit od jiných návrhů aplikací, se kterými jste se už setkali. + +Zatím nejste obeznámeni se základy web3? Podívejte se na [**Centrum vzdělávání**](/learn/). + +## Začněte s uživatelským výzkumem {#start-with-user-research} + +Efektivní design jde nad rámec tvorby vizuálně atraktivních uživatelských rozhraní. Zahrnuje hluboké pochopení potřeb, cílů a motivačních faktorů uživatelů. Proto všem návrhářům důrazně doporučujeme, aby si osvojili proces návrhu, jako je [**proces dvojitého diamantu**](https://en.wikipedia.org/wiki/Double_Diamond_\(design_process_model\)), aby bylo zajištěno, že jejich práce bude promyšlená a cílevědomá. + +- [Web3 potřebuje více UX výzkumníků a designérů](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) – Přehled současné vyspělosti designu +- [Jednoduchý průvodce UX výzkumem ve webu3](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) – Jednoduchý průvodce, jak provádět výzkum +- [Jak přistupovat k rozhodnutím ohledně UX ve webu3](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) – Stručný přehled kvantitativního a kvalitativního výzkumu a rozdílů mezi nimi (video, 6 min) +- [Být UX výzkumníkem ve webu3](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) – Osobní pohled na to, jaké to je být UX výzkumníkem ve webu3 + +## Výzkumné studie ve webu3 {#research-in-web3} + +Níže najdete kurátorský seznam uživatelských výzkumů, které byly ve web3 realizovány v minulosti: Může vám pomoci s designovými a produktovými rozhodnutími nebo posloužit jako inspirace k provedení vlastního výzkumu. + +| Oblast zájmu | Název | +| :------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Krypto onboarding | [The Reown Pulse 2024: Nálada a používání kryptoměn spotřebiteli](https://reown.com/blog/unveiling-walletconnects-consumer-crypto-report) | +| Krypto onboarding | [CRADL: UX v kryptoměnách](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| Krypto onboarding | [CRADL: On-boarding do světa kryptoměn](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| Krypto onboarding | [Zpráva o UX Bitcoinu](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| Krypto onboarding | [Consensys: Stav vnímání webu3 ve světě v roce 2023](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| Krypto onboarding | [NEAR: Urychlení cesty k přijetí](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Staking | [OpenUX: UX operátora uzlu Rocket Pool](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| Staking | [Staking: Klíčové trendy, poznatky a předpovědi – Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| Staking | [Víceaplikační staking](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20\(MAS\)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [Aktualizace výzkumu DAO za rok 2022: Co potřebují tvůrci DAO?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [Pooly krytí](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [Consensys: Zpráva o uživatelském výzkumu DeFi 2022](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| Metaverzum | [Metaverzum: Zpráva o uživatelském výzkumu](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| Metaverzum | [Jako na safari: Výzkum uživatelů v metaverzu](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (video, 27 min) | + +## Design pro web3 {#design-for-web3} + +- [Web3 UX Design Handbook](https://web3ux.design/) – Praktický průvodce návrhem aplikací pro web3 +- [Principy designu pro web3](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) – Rámec pravidel UX pro dapps založené na blockchainu +- [Principy designu pro blockchain](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) – Zkušenosti designérského týmu pro blockchain v IBM +- [Neueux.com](https://neueux.com/apps) – Knihovna uživatelského rozhraní s uživatelskými toky s různými možnostmi filtrování +- [Web3's Usability Crisis: What You NEED to Know!](https://www.youtube.com/watch?v=oBSXT_6YDzg) – Panelová diskuze o úskalích tvorby projektů zaměřených na vývojáře (video, 34 min) + +## Začínáme {#getting-started} + +- [Heuristiky pro web3](/developers/docs/design-and-ux/heuristics-for-web3/) – 7 heuristik pro návrh rozhraní webu3 +- [Osvědčené postupy pro design DEX](/developers/docs/design-and-ux/dex-design-best-practice/) – Průvodce navrhováním decentralizovaných burz + +## Případové studie designu pro web3 {#design-case-studies} + +- [Deep Work Studio](https://www.deepwork.studio/case-studies) +- [Prodej NFT na OpenSea](https://builtformars.com/case-studies/opensea) +- [Analýza UX peněženek a jak se musí změnit](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (video, 20 min) + +## Odměny za design {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Buildbox hackathons](https://app.buidlbox.io/) +- [ETHGlobal hackathons](https://ethglobal.com/) + +## Designérské DAO a komunity {#design-daos-and-communities} + +Zapojte se do profesionálních komunitně řízených organizací nebo se připojte ke skupinám designérů a diskutujte o designu, výzkumu a souvisejících tématech a trendech s ostatními členy. + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) + +## Design systémy a další designérské zdroje {#design-systems-and-resources} + +- [Optimism Design](https://www.figma.com/@optimism) (Figma) +- [Design systém Ethereum.org](https://www.figma.com/@ethdotorg) (Figma) +- [Finity, design systém od Polygonu](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [Design systém Kleros](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [Design systém Safe](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [Design systém ENS](https://thorin.ens.domains/) +- [Design systém Mirror](https://degen-xyz.vercel.app/) + +**Články a projekty uvedené na této stránce nejsou oficiálními doporučeními a jsou zde uvedeny pouze pro informační účely.** +Odkazy na tuto stránku přidáváme na základě kritérií v našich [zásadách pro zařazování do seznamu](/contributing/design/adding-design-resources). Pokud chcete, abychom přidali projekt/článek, upravte tuto stránku na [GitHubu](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/cs/developers/docs/development-networks/index.md b/public/content/translations/cs/developers/docs/development-networks/index.md new file mode 100644 index 00000000000..6df64342f8f --- /dev/null +++ b/public/content/translations/cs/developers/docs/development-networks/index.md @@ -0,0 +1,71 @@ +--- +title: "Vývojové sítě" +description: "Přehled vývojových sítí a dostupných nástrojů, nápomocných při vytváření aplikací pro Ethereum." +lang: cs +--- + +Když vytváříte aplikaci pro Ethereum se smart kontrakty, budete ji chtít před nasazením spustit nejdříve v místní síti, abyste zjistili, jak funguje. + +Podobně jako můžete na svém počítači spustit lokální server pro vývoj webu, můžete pomocí vývojové sítě vytvořit lokální instanci blockchainu a otestovat svou dapp. Tyto vývojové sítě Etherea poskytují funkce, které umožňují mnohem rychlejší iteraci než veřejná testovací síť (například nemusíte řešit získávání ETH). + +## Předpoklady {#prerequisites} + +Měli byste rozumět [základům Ethereum stacku](/developers/docs/ethereum-stack/) a [ethereových sítí](/developers/docs/networks/), než se pustíte do vývojových sítí. + +## Co je to vývojová síť? {#what-is-a-development-network} + +Vývojové sítě jsou v zásadě klienti Etherea (implementace Etherea) navrženi speciálně pro lokální vývoj. + +**Proč jen lokálně nespustit standardní uzel Etherea?** + +_Můžete_ [spustit uzel](/developers/docs/nodes-and-clients/#running-your-own-node), ale protože vývojové sítě jsou účelově vytvořeny pro vývoj, často obsahují praktické funkce, jako jsou: + +- Deterministické naplnění vašeho lokálního blockchainu daty (např. účty se zůstatky ETH) +- Okamžitá produkce bloků s každou přijatou transakcí, a to popořadě a bez zpoždění +- Vylepšená funkce debugování a protokolování + +## Dostupné nástroje {#available-projects} + +**Poznámka**: Většina [vývojových frameworků](/developers/docs/frameworks/) obsahuje vestavěnou vývojovou síť. Doporučujeme začít s frameworkem pro [nastavení vašeho lokálního vývojového prostředí](/developers/local-environment/). + +### Hardhat Network {#hardhat-network} + +Lokální síť Etherea určená pro vývoj. Umožňuje nasazovat kontrakty, spouštět testy a ladit kód. + +Síť Hardhat Network je integrovaná s Hardhatem, vývojovým prostředím Etherea pro profesionály. + +- [Webové stránky](https://hardhat.org/) +- [GitHub](https://github.com/NomicFoundation/hardhat) + +### Lokální Beacon Chainy {#local-beacon-chains} + +Někteří konsensuální klienti mají vestavěné nástroje pro spuštění lokálních Beacon Chainů pro účely testování. Jsou k dispozici pokyny pro Lighthouse, Nimbus a Lodestar: + +- [Lokální testovací síť s použitím Lodestar](https://chainsafe.github.io/lodestar/contribution/advanced-topics/setting-up-a-testnet#post-merge-local-testnet/) +- [Lokální testovací síť s použitím Lighthouse](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) + +### Veřejné testovací řetězce Etherea {#public-beacon-testchains} + +Existují také dvě udržované veřejné testovací implementace Etherea: Sepolia a Hoodi. Doporučenou testovací sítí s dlouhodobou podporou je Hoodi, na které může kdokoli volně validovat. Sepolia používá sadu validátorů s oprávněním, což znamená, že na této testovací síti není obecný přístup k novým validátorům. + +- [Hoodi Staking Launchpad](https://hoodi.launchpad.ethereum.org/) + +### Kurtosis Ethereum Package {#kurtosis} + +Kurtosis je systém pro sestavování testovacích prostředí s více kontejnery, který vývojářům umožňuje lokálně spouštět reprodukovatelné instance blockchainových sítí. + +Balíček Ethereum Kurtosis lze použít k rychlému vytvoření parametrizovatelné, vysoce škálovatelné a soukromé testovací sítě Ethereum přes Docker nebo Kubernetes. Balíček podporuje všechny hlavní klienty exekuční vrstvy (EL) a vrstvy konsensu (CL). Kurtosis elegantně zpracovává všechna lokální mapování portů a servisní připojení pro reprezentativní síť, která se má používat v pracovních postupech validace a testování týkajících se základní infrastruktury Etherea. + +- [Ethereum network package](https://github.com/kurtosis-tech/ethereum-package) +- [Webové stránky](https://www.kurtosis.com/) +- [GitHub](https://github.com/kurtosis-tech/kurtosis) +- [Dokumentace](https://docs.kurtosis.com/) + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Související témata {#related-topics} + +- [Vývojářské frameworky](/developers/docs/frameworks/) +- [Nastavení lokálního vývojového prostředí](/developers/local-environment/) diff --git a/public/content/translations/cs/developers/docs/ethereum-stack/index.md b/public/content/translations/cs/developers/docs/ethereum-stack/index.md new file mode 100644 index 00000000000..2f50ff8387a --- /dev/null +++ b/public/content/translations/cs/developers/docs/ethereum-stack/index.md @@ -0,0 +1,61 @@ +--- +title: "Úvod do stacku Etherea" +description: "Průvodce různými vrstvami Ethereum zásobníku a tím, jak do sebe zapadají." +lang: cs +--- + +Stejně jako každý softwarový zásobník se i kompletní „Ethereum zásobník“ bude lišit projekt od projektu v závislosti na vašich cílech. + +Existují však základní komponenty Etherea, které pomáhají vytvořit mentální model interakce softwarových aplikací s ethereovým blockchainem. Pochopení vrstev zásobníku vám pomůže porozumět různým způsobům, jak lze Ethereum integrovat do softwarových projektů. + +## Úroveň 1: Ethereum Virtual Machine {#ethereum-virtual-machine} + +[Virtuální stroj Etherea (EVM)](/developers/docs/evm/) je běhové prostředí pro chytré kontrakty na Ethereu. Všechny chytré kontrakty a změny stavu na blockchainu Etherea jsou prováděny [transakcemi](/developers/docs/transactions/). EVM zajišťuje veškeré zpracování transakcí v síti Ethereum. + +Stejně jako u každého virtuálního stroje vytváří EVM úroveň abstrakce mezi prováděným kódem a vykonávajícím strojem (uzlem Etherea). V současné době běží EVM na tisících uzlů rozmístěných po celém světě. + +Pod kapotou používá EVM sadu instrukcí opkódu k provádění konkrétních úloh. Těchto (140 unikátních) opkódů umožňuje, aby byl EVM [Turingovsky kompletní](https://en.wikipedia.org/wiki/Turing_completeness), což znamená, že pokud má dostatek zdrojů, je schopen vypočítat téměř cokoli. + +Jako vývojář dapps nemusíte o EVM vědět o moc víc než to, že existuje a spolehlivě a bez výpadků pohání všechny aplikace na Ethereu. + +## Úroveň 2: Chytré kontrakty {#smart-contracts} + +[Chytré kontrakty](/developers/docs/smart-contracts/) jsou spustitelné programy, které běží na ethereovém blockchainu. + +Chytré kontrakty se píší pomocí specifických [programovacích jazyků](/developers/docs/smart-contracts/languages/), které se kompilují do bajtkódu EVM (nízkoúrovňové strojové instrukce nazývané opkódy). + +Chytré kontrakty neslouží jen jako open source knihovny, ale jsou to v podstatě otevřené služby API, které jsou neustále v provozu a nelze je vypnout. Chytré kontrakty poskytují veřejné funkce, se kterými mohou uživatelé a aplikace ([dapps](/developers/docs/dapps/)) interagovat bez nutnosti povolení. Jakákoli aplikace se může integrovat s nasazenými chytrými kontrakty a skládat tak funkcionalitu, jako je přidávání [datových kanálů](/developers/docs/oracles/) nebo podpora směny tokenů. Kdokoli může navíc na Ethereum nasadit nové chytré kontrakty a přidat tak vlastní funkcionalitu, která bude vyhovovat potřebám jeho aplikace. + +Jako vývojář dec. aplikací budete muset psát smart kontrakty pouze v případě, že budete chtít přidat vlastní funkcionalitu do blockchainu Etherea. Možná zjistíte, že většiny nebo všech potřeb vašeho projektu dosáhnete pouhou integrací s již existujícími smart kontrakty, například pokud chcete podporovat platby ve stablecoinech nebo umožnit decentralizovanou výměnu tokenů. + +## Úroveň 3: Ethereové uzly {#ethereum-nodes} + +Aby mohla aplikace interagovat s ethereovým blockchainem, musí se připojit k [ethereovému uzlu](/developers/docs/nodes-and-clients/). Připojení k uzlu vám umožní číst data z blockchainu a/nebo posílat transakce do sítě. + +Ethereum uzly jsou počítače se spuštěným softwarem - Ethereum klientem. Klient je implementace Etherea, která ověřuje všechny transakce v každém bloku, čímž zajišťuje bezpečnost sítě a přesnost dat. **Ethereové uzly JSOU ethereový blockchain**. Společně uchovávají stav blockchainu Etherea a dosahují konsensu o transakcích, které mají za cíl měnit stav blockchainu. + +Připojením vaší aplikace k ethereovému uzlu (prostřednictvím [JSON-RPC API](/developers/docs/apis/json-rpc/)) je vaše aplikace schopna číst data z blockchainu (například zůstatky na uživatelských účtech) a také vysílat do sítě nové transakce (například převod ETH mezi uživatelskými účty nebo provádění funkcí chytrých kontraktů). + +## Úroveň 4: Klientská API pro Ethereum {#ethereum-client-apis} + +Mnoho pomocných knihoven (vytvořených a spravovaných open source komunitou Etherea) umožňuje vašim aplikacím připojit se k ethereovému blockchainu a komunikovat s ním. + +Pokud je vaše uživatelská aplikace webová, můžete si zvolit `npm install` [JavaScript API](/developers/docs/apis/javascript/) přímo do frontendu. Nebo se možná rozhodnete implementovat tuto funkcionalitu na straně serveru pomocí API pro [Python](/developers/docs/programming-languages/python/) nebo [Javu](/developers/docs/programming-languages/java/). + +I když tato API nejsou nezbytnou součástí zásobníku, abstrahují od velké části složitosti přímé interakce s ethereovým uzlem. Poskytují také pomocné funkce (např. převod ETH na Gwei), takže jako vývojář můžete strávit méně času řešením složitostí klientů Etherea a více času se soustředit na funkcionalitu specifickou pro vaši aplikaci. + +## Úroveň 5: Aplikace pro koncové uživatele {#end-user-applications} + +Na nejvyšší úrovni zásobníku jsou aplikace určené pro uživatele. Jedná se o standardní aplikace, které dnes běžně vytváříte a používáte: především webové a mobilní aplikace. + +Způsob vývoje těchto uživatelských rozhraní se v podstatě nemění. Uživatelé často nebudou potřebovat vědět, že aplikace, kterou používají, je vytvořena pomocí blockchainu. + +## Jste připraveni vybrat si svůj zásobník? {#ready-to-choose-your-stack} + +Podívejte se na našeho průvodce [nastavením místního vývojového prostředí](/developers/local-environment/) pro vaši ethereovou aplikaci. + +## Další čtení {#further-reading} + +- [Architektura aplikace Web 3.0](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ diff --git a/public/content/translations/cs/developers/docs/evm/index.md b/public/content/translations/cs/developers/docs/evm/index.md index 8e2502a19bd..07b75a0fb7b 100644 --- a/public/content/translations/cs/developers/docs/evm/index.md +++ b/public/content/translations/cs/developers/docs/evm/index.md @@ -1,77 +1,87 @@ --- -title: Virtuální stroj Etherea (EVM) -description: Úvod do virtuálního stroje Etherea a jeho vztah ke stavu, transakcím a chytrým kontraktům. +title: "Virtuální stroj Etherea (EVM)" +description: "Úvod do virtuálního stroje Etherea a jeho vztah ke stavu, transakcím a chytrým kontraktům." lang: cs --- -Virtuální stroj Etherea (EVM) je decentralizované virtuální prostředí, které konzistentně a bezpečně vykonává kód na všech uzlech Etherea. Uzly spouštějí EVM, aby vykonávaly chytré kontrakty, přičemž používají jednotky „[paliva](/developers/docs/gas/)“ k měření výpočetního úsilí potřebného pro tyto [operace](/developers/docs/evm/opcodes/), což zajišťuje efektivní alokaci zdrojů a bezpečnost sítě. +Virtuální stroj Etherea (EVM) je decentralizované virtuální prostředí, které konzistentně a bezpečně vykonává kód na všech uzlech Etherea. Uzly spouštějí EVM k provádění chytrých kontraktů a používají "[palivo](/developers/docs/gas/)" k měření výpočetní náročnosti [operací](/developers/docs/evm/opcodes/), čímž zajišťují efektivní alokaci zdrojů a bezpečnost sítě. ## Předpoklady {#prerequisites} -Pro pochopení EVM je nutné mít základní povědomí o běžné terminologii v informatice, jako jsou [bajty](https://wikipedia.org/wiki/Byte), [paměť](https://wikipedia.org/wiki/Computer_memory) a [zásobník](https://wikipedia.org/wiki/Stack_(abstract_data_type)). Také se hodí mít znalosti z oblasti kryptografie a blockchainu, např. o [hashovacích funkcích](https://wikipedia.org/wiki/Cryptographic_hash_function) a [Merkle tree](https://wikipedia.org/wiki/Merkle_tree). +Pro pochopení EVM je nutné mít základní znalosti běžné terminologie v informatice, jako jsou [bajty](https://wikipedia.org/wiki/Byte), [paměť](https://wikipedia.org/wiki/Computer_memory) a [zásobník](https://wikipedia.org/wiki/Stack_\(abstract_data_type\)). Také by bylo užitečné se seznámit s kryptografickými/blockchainovými koncepty, jako jsou [hašovací funkce](https://wikipedia.org/wiki/Cryptographic_hash_function) a [Merkleho strom](https://wikipedia.org/wiki/Merkle_tree). ## Od účetní knihy ke stavovému stroji {#from-ledger-to-state-machine} Přirovnání k „distribuované účetní knize“ se často používá k popisu blockchainů, jako je Bitcoin, které mají decentralizovanou měnu s využitím základních nástrojů kryptografie. Účetní kniha udržuje záznam aktivit za současného dodržování souboru pravidel, která určují, co může a nemůže uživatel dělat při úpravě této knihy. Např. bitcoinová adresa nemůže utratit více Bitcoinů, než kolik jich předtím obdržela. Tato pravidla jsou základem všech transakcí na Bitcoinu a mnoha dalších blockchainech. -Ethereum sice má vlastní nativní kryptoměnu (ether), která se řídí téměř stejnými intuitivními pravidly, ale zároveň umožňuje mnohem výkonnější funkce: [chytré kontrakty](/developers/docs/smart-contracts/). Pro tuto složitější funkci potřebujeme sofistikovanější přirovnání. Namísto distribuované účetní knihy je Ethereum distribuovaný [stavový stroj](https://wikipedia.org/wiki/Finite-state_machine). Stav Etherea je velká datová struktura, která obsahuje nejen všechny účty a zůstatky, ale také _stav stroje_, který se může měnit od bloku k bloku podle předem definovaného souboru pravidel a který může vykonávat libovolný strojový kód. Specifická pravidla pro změnu stavu od bloku k bloku jsou definována v EVM. +Ethereum sice má svou vlastní nativní kryptoměnu (ether), která se řídí téměř úplně stejnými intuitivními pravidly, ale zároveň umožňuje mnohem výkonnější funkci: [chytré kontrakty](/developers/docs/smart-contracts/). Pro tuto složitější funkci potřebujeme sofistikovanější přirovnání. Místo distribuované účetní knihy je Ethereum distribuovaný [stavový stroj](https://wikipedia.org/wiki/Finite-state_machine). Stav Etherea je velká datová struktura, která obsahuje nejen všechny účty a zůstatky, ale také _stav stroje_, který se může měnit z bloku na blok podle předem definované sady pravidel a který může vykonávat libovolný strojový kód. Specifická pravidla pro změnu stavu od bloku k bloku jsou definována v EVM. -![Diagram znázorňující složení EVM](./evm.png) _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram znázorňující složení EVM](./evm.png) +_Diagram převzatý z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ -## Funkce změny stavu na Ethereu {#the-ethereum-state-transition-function} +## Funkce přechodu stavu Etherea {#the-ethereum-state-transition-function} -EVM se chová jako matematická funkce: Na základě vstupu produkuje deterministický výstup. Je tedy užitečné formálněji popsat Ethereum jako systém s **funkcí změny stavu**: +EVM se chová jako matematická funkce: Na základě vstupu produkuje deterministický výstup. Je proto velmi užitečné formálněji popsat Ethereum tak, že má **funkci přechodu stavu**: ``` Y(S, T)= S' ``` -Na základě starého platného stavu `(S)` a nové sady platných transakcí `(T)` funkce změny stavu Etherea `Y(S, T)` vytvoří nový platný výstupní stav `S'`. +Je-li dán starý platný stav `(S)` a nová sada platných transakcí `(T)`, funkce přechodu stavu Etherea `Y(S, T)` vytvoří nový platný výstupní stav `S'` ### Stav {#state} -V kontextu Etherea je stav obrovská datová struktura nazývaná [modifikovaný Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), která udržuje všechny [účty](/developers/docs/accounts/) propojené pomocí hashů a redukovatelné na jediný kořenový hash uložený na blockchainu. +V kontextu Etherea je stav obrovská datová struktura zvaná [modifikovaný Merkle Patricia Trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), která uchovává všechny [účty](/developers/docs/accounts/) propojené haši a redukovatelné na jeden kořenový haš uložený na blockchainu. ### Transakce {#transactions} Transakce jsou kryptograficky podepsané instrukce poslané z účtů. Existují dva typy transakcí: Ty, jejich výsledkem je volání zpráv (message calls), a ty, které vedou k vytvoření kontraktu. -Vytvoření kontraktu vede k vytvoření nového kontraktového účtu, který obsahuje zkompilovaný bytecode [chytrého kontraktu](/developers/docs/smart-contracts/anatomy/). Kdykoli jiný účet vyšle zprávu na tento kontrakt, vykoná se jeho bytecode. +Vytvoření kontraktu vede k vytvoření nového účtu kontraktu, který obsahuje zkompilovaný bytecode [chytrého kontraktu](/developers/docs/smart-contracts/anatomy/). Kdykoli jiný účet vyšle zprávu na tento kontrakt, vykoná se jeho bytecode. ## Instrukce EVM {#evm-instructions} -EVM funguje jako [zásobníkový stroj](https://wikipedia.org/wiki/Stack_machine) s hloubkou 1 024 položek. Každá položka je 256bitové slovo, které bylo zvoleno pro snadné použití s 256bitovou kryptografií (např. hashe Keccak-256 nebo podpisy secp256k1). +EVM se spouští jako [zásobníkový stroj](https://wikipedia.org/wiki/Stack_machine) s hloubkou 1024 položek. Každá položka je 256bitové slovo, které bylo zvoleno pro snadné použití s 256bitovou kryptografií (např. hashe Keccak-256 nebo podpisy secp256k1). -Během vykonávání EVM udržuje přechodnou _paměť_ (jako bajtové pole adresované slovy), která nepřetrvává mezi transakcemi. +Během provádění udržuje EVM přechodnou _paměť_ (jako bajtové pole adresované slovem), která se mezi transakcemi neuchovává. -Kontrakty však obsahují trie _úložiště_ Merkle Patricia (jako pole adresovatelné slovy), které je spojeno s příslušným účtem a je součástí globálního stavu. +### Přechodné úložiště -Zkompilovaný bytecode chytrého kontraktu se vykonává jako řada [opkódů](/developers/docs/evm/opcodes) EVM, které provádějí standardní zásobníkové operace jako `XOR`, `AND`, `ADD`, `SUB` atd. EVM také implementuje několik blockchainově specifických zásobníkových operací, jako je `ADDRESS`, `BALANCE`, `BLOCKHASH` atd. +Přechodné úložiště je úložiště klíč–hodnota pro jednotlivé transakce, ke kterému se přistupuje pomocí opkódů `TSTORE` a `TLOAD`. Zůstává zachováno napříč všemi interními voláními během jedné transakce, ale na konci transakce se vymaže. Na rozdíl od paměti je přechodné úložiště modelováno jako součást stavu EVM, nikoli jako součást exekučního rámce, ale není zapsáno do globálního stavu. Přechodné úložiště umožňuje úsporné dočasné sdílení stavu mezi interními voláními během transakce. -![Diagram znázorňující, kde jsou potřeba jednotky pro EVM operace](../gas/gas.png) _Diagram převzat z [ilustrovaného Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +### Úložiště + +Kontrakty obsahují Merkle Patricia _úložiště_ trie (jako pole slov adresovatelné slovy), které je spojeno s příslušným účtem a je součástí globálního stavu. Toto trvalé úložiště se liší od přechodného úložiště, které je k dispozici pouze po dobu trvání jedné transakce a netvoří součást trvalého úložiště trie účtu. + +### Opkódy + +Zkompilovaný bytecode chytrého kontraktu se provádí jako řada [opkódů](/developers/docs/evm/opcodes) EVM, které provádějí standardní zásobníkové operace jako `XOR`, `AND`, `ADD`, `SUB` atd. EVM také implementuje řadu blockchainově specifických operací se zásobníkem, jako jsou `ADDRESS`, `BALANCE`, `BLOCKHASH` atd. Sada opkódů zahrnuje také `TSTORE` a `TLOAD`, které poskytují přístup k přechodnému úložišti. + +![Diagram ukazující, kde je pro operace EVM potřeba palivo](../gas/gas.png) +_Diagramy převzaty z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ ## Implementace EVM {#evm-implementations} Všechny implementace EVM musí dodržovat specifikaci popsanou v Ethereum Yellowpaperu. -Během devítileté historie Etherea prošlo EVM několika revizemi a existuje několik implementací EVM v různých programovacích jazycích. +Během desetileté historie Etherea prošel EVM několika revizemi a existuje několik implementací EVM v různých programovacích jazycích. -[Exekuční klienty Etherea](/developers/docs/nodes-and-clients/#execution-clients) obsahují implementaci EVM. Navíc existuje několik samostatných implementací, včetně: +[Exekuční klienti Etherea](/developers/docs/nodes-and-clients/#execution-clients) zahrnují implementaci EVM. Navíc existuje několik samostatných implementací, včetně: -- [Py-EVM](https://github.com/ethereum/py-evm) – _Python_ -- [evmone](https://github.com/ethereum/evmone) – _C++_ -- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) – _JavaScript_ -- [revm](https://github.com/bluealloy/revm) – _Rust_ +- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ +- [evmone](https://github.com/ethereum/evmone) - _C++_ +- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ +- [revm](https://github.com/bluealloy/revm) - _Rust_ -## Další informace {#further-reading} +## Další čtení {#further-reading} - [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) - [Jellopaper alias KEVM: Sémantika EVM v K](https://jellopaper.org/) - [The Beigepaper](https://github.com/chronaeon/beigepaper) -- [Opkódy Virtuálního stroje Etherea](https://www.ethervm.io/) -- [Interaktivní reference pro opkódy Virtuálního stroje Etherea](https://www.evm.codes/) +- [Opkódy Ethereum Virtual Machine](https://www.ethervm.io/) +- [Interaktivní reference pro opkódy Ethereum Virtual Machine](https://www.evm.codes/) - [Krátký úvod v dokumentaci Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) -- [Kniha Mastering Ethereum – Virtuální stroj Etherea](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) +- [Mastering Ethereum - The Ethereum Virtual Machine](https://github.com/ethereumbook/ethereumbook/blob/openedition/13evm.asciidoc) ## Související témata {#related-topics} diff --git a/public/content/translations/cs/developers/docs/evm/opcodes/index.md b/public/content/translations/cs/developers/docs/evm/opcodes/index.md index 50f17e9f2eb..165085b5dc8 100644 --- a/public/content/translations/cs/developers/docs/evm/opcodes/index.md +++ b/public/content/translations/cs/developers/docs/evm/opcodes/index.md @@ -1,174 +1,177 @@ --- -title: Operační kódy pro EVM -description: Seznam všech dostupných operačních kódů pro Virtuální stroj Etherea. +title: "Operační kódy pro EVM" +description: "Seznam všech dostupných operačních kódů pro Virtuální stroj Etherea." lang: cs --- ## Přehled {#overview} -Toto je aktualizovaná verze referenční stránky EVM na [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). Rovněž čerpá z [Yellow Paperu](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paperu](https://jellopaper.org/evm/) a implementace v [Geth](https://github.com/ethereum/go-ethereum). Tento dokument má být přístupnou referencí, ale není nijak zvlášť důkladný. Pokud si chcete být jisti správností a být si vědomi všech hraničních případů, doporučujeme vám používat Jello Paper nebo implementaci klienta. +Toto je aktualizovaná verze referenční stránky EVM na [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes). +Čerpáno také z [Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf), [Jello Paper](https://jellopaper.org/evm/) a implementace [geth](https://github.com/ethereum/go-ethereum). +Tento dokument má být přístupnou referencí, ale není nijak zvlášť důkladný. +Pokud si chcete být jisti správností a být si vědomi všech hraničních případů, doporučujeme vám používat Jello Paper nebo implementaci klienta. -Hledáte interaktivní referenci? Zkuste [evm.codes.](https://www.evm.codes/). +Hledáte interaktivní referenci? Podívejte se na [evm.codes](https://www.evm.codes/). -Pro operace s dynamickými poplatky se podívejte na [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). +Pro operace s dynamickými náklady na plyn viz [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). -💡Rychlý tip: Chcete-li zobrazit celé řádky, použijte `[shift] + scroll` pro horizontální posun na ploše. +💡 Rychlý tip: Chcete-li zobrazit celé řádky, použijte `[shift] + scroll` pro horizontální posouvání na počítači. -| Zásobník | Název | Palivo | Počáteční zásobník | Výsledný zásobník | Paměť/úložiště | Poznámky | -|:--------:|:-------------- |:-----------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 00 | STOP | 0 | | | | halt execution | -| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | -| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | -| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | -| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | -| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | -| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | -| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | -| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | -| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | -| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | -| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | -| 0C-0F | _invalid_ | | | | | | -| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | -| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | -| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | -| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | -| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | -| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | -| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | -| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | -| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | -| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | -| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | -| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | -| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | -| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | -| 1E-1F | _invalid_ | | | | | | -| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | -| 21-2F | _invalid_ | | | | | | -| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | -| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | -| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | -| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | -| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | -| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | -| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | -| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | -| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | -| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | -| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | -| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | -| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | -| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | -| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | -| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | -| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | -| 41 | COINBASE | 2 | `.` | `block.coinbase` | | adresa navrhovatele aktuálního bloku | -| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | -| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | -| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | -| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | -| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | -| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | -| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | -| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | -| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | blob base fee of current block ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | -| 4B-4F | _invalid_ | | | | | | -| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | -| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | -| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory | -| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory | -| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | -| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage | -| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | -| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | -| 58 | PC | 2 | `.` | `$pc` | | program counter | -| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | -| 5A | GAS | 2 | `.` | `gasRemaining` | | | -| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | -| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | read word from transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | write word to transient storage ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | copy memory from one area to another ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | -| 5F | PUSH0 | 2 | `.` | `uint8` | | push the constant value 0 onto stack | -| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | -| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | -| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | -| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | -| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | -| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | -| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | -| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | -| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | -| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | -| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | -| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | -| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | -| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | -| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | -| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | -| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | -| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | -| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | -| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | -| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | -| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | -| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | -| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | -| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | -| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | -| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | -| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | -| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | -| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | -| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | -| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | -| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | -| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | -| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | -| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | -| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | -| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | -| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | -| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | -| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | -| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | -| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | -| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | -| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | -| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | -| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | -| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | -| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | -| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | -| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | -| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | -| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | -| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | -| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | -| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | -| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | -| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | -| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | -| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | -| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | -| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | -| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | -| A5-EF | _invalid_ | | | | | | -| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | -| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | -| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | -| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | -| F6-F9 | _invalid_ | | | | | | -| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| FB-FC | _invalid_ | | | | | | -| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | -| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | -| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | sends all ETH to `addr`; if executed in the same transaction as a contract was created it destroys the contract | +| Zásobník | Název | Palivo | Počáteční zásobník | Výsledný zásobník | Paměť/úložiště | Poznámky | | +| :------: | :------------- | :---------------------------------------------------------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | +| 00 | STOP | 0 | | | | zastavit provádění | | +| 01 | ADD | 3 | `a, b` | `a + b` | | sčítání (u)int256 modulo 2\*\*256 | | +| 02 | MUL | 5 | `a, b` | `a * b` | | násobení (u)int256 modulo 2\*\*256 | | +| 03 | SUB | 3 | `a, b` | `a - b` | | odčítání (u)int256 modulo 2\*\*256 | | +| 04 | DIV | 5 | `a, b` | `a // b` | | dělení uint256 | | +| 05 | SDIV | 5 | `a, b` | `a // b` | | dělení int256 | | +| 06 | MOD | 5 | `a, b` | `a % b` | | modulo uint256 | | +| 07 | SMOD | 5 | `a, b` | `a % b` | | modulo int256 | | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | sčítání (u)int256 modulo N | | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | násobení (u)int256 modulo N | | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | umocňování uint256 modulo 2\*\*256 | | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [rozšíření znaménka](https://wikipedia.org/wiki/Sign_extension) `x` z `(b+1)` bajtů na 32 bajtů | | +| 0C-0F | _neplatné_ | | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 menší než | | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 větší než | | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 menší než | | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 větší než | | +| 14 | EQ | 3 | `a, b` | `a == b` | | rovnost (u)int256 | | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 je nula | | +| 16 | AND | 3 | `a, b` | `a && b` | | bitové AND | | +| 17 | OR | 3 | `a, b` | `a \\|\\| b` | | bitové OR | | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitové XOR | | +| 19 | NOT | 3 | `a` | `~a` | | bitové NOT | | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`-tý bajt (u)int256 `x`, zleva | | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | posun vlevo | | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logický posun vpravo | | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | aritmetický posun vpravo | | +| 1E-1F | _neplatné_ | | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | | +| 21-2F | _neplatné_ | | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | adresa prováděné smlouvy | | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | zůstatek, ve wei | | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | adresa, která zahájila transakci | | +| 33 | CALLER | 2 | `.` | `msg.sender` | | adresa odesílatele zprávy | | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | hodnota zprávy, ve wei | | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | přečíst slovo z dat zprávy na indexu `idx` | | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | délka dat zprávy, v bajtech | | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | kopírovat data zprávy | | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | délka kódu prováděné smlouvy, v bajtech | | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | kopírovat bajtkód prováděné smlouvy | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | cena plynu transakce, ve wei za jednotku plynu [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | velikost kódu na adrese, v bajtech | | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | kopírovat kód z `addr` | | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | velikost vrácených dat z posledního externího volání, v bajtech | | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | kopírovat vrácená data z posledního externího volání | | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | haš = addr.exists ? keccak256(addr.code) : 0 | | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | adresa navrhovatele aktuálního bloku | | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | časové razítko aktuálního bloku | | +| 43 | NUMBER | 2 | `.` | `block.number` | | číslo aktuálního bloku | | +| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | maják náhodnosti | | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | limit transakčních poplatků aktuálního bloku | | +| 46 | CHAINID | 2 | `.` | `chain_id` | | vložit aktuální [ID řetězce](https://eips.ethereum.org/EIPS/eip-155) na zásobník | | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | zůstatek prováděné smlouvy, ve wei | | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | základní poplatek aktuálního bloku | | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | základní poplatek blobu aktuálního bloku ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | | +| 4B-4F | _neplatné_ | | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | odebrat položku z vrcholu zásobníku a zahodit ji | | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | přečíst slovo z paměti na offsetu `ost` | | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | zapsat slovo do paměti | | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | zapsat jeden bajt do paměti | | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | přečíst slovo z úložiště | | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | zapsat slovo do úložiště | | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` označuje, že `pc` se přiřadí, pouze pokud je `dst` platný cíl skoku | | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ?` dst : $pc + 1` | | +| 58 | PC | 2 | `.` | `$pc` | | čítač programu | | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | velikost paměti v aktuálním kontextu provádění, v bajtech | | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | | +| 5B | JUMPDEST | 1 | | | označit platný cíl skoku | platný cíl skoku, například cíl skoku, který není uvnitř dat pro push | | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | přečíst slovo z dočasného úložiště ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | zapsat slovo do dočasného úložiště ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | | +| 5E | MCOPY | 3+3\*words+[A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | kopírovat paměť z jedné oblasti do druhé ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | | +| 5F | PUSH0 | 2 | `.` | `uint8` | | vložit konstantní hodnotu 0 na zásobník | | +| 60 | PUSH1 | 3 | `.` | `uint8` | | vložit 1bajtovou hodnotu na zásobník | | +| 61 | PUSH2 | 3 | `.` | `uint16` | | vložit 2bajtovou hodnotu na zásobník | | +| 62 | PUSH3 | 3 | `.` | `uint24` | | vložit 3bajtovou hodnotu na zásobník | | +| 63 | PUSH4 | 3 | `.` | `uint32` | | vložit 4bajtovou hodnotu na zásobník | | +| 64 | PUSH5 | 3 | `.` | `uint40` | | vložit 5bajtovou hodnotu na zásobník | | +| 65 | PUSH6 | 3 | `.` | `uint48` | | vložit 6bajtovou hodnotu na zásobník | | +| 66 | PUSH7 | 3 | `.` | `uint56` | | vložit 7bajtovou hodnotu na zásobník | | +| 67 | PUSH8 | 3 | `.` | `uint64` | | vložit 8bajtovou hodnotu na zásobník | | +| 68 | PUSH9 | 3 | `.` | `uint72` | | vložit 9bajtovou hodnotu na zásobník | | +| 69 | PUSH10 | 3 | `.` | `uint80` | | vložit 10bajtovou hodnotu na zásobník | | +| 6A | PUSH11 | 3 | `.` | `uint88` | | vložit 11bajtovou hodnotu na zásobník | | +| 6B | PUSH12 | 3 | `.` | `uint96` | | vložit 12bajtovou hodnotu na zásobník | | +| 6C | PUSH13 | 3 | `.` | `uint104` | | vložit 13bajtovou hodnotu na zásobník | | +| 6D | PUSH14 | 3 | `.` | `uint112` | | vložit 14bajtovou hodnotu na zásobník | | +| 6E | PUSH15 | 3 | `.` | `uint120` | | vložit 15bajtovou hodnotu na zásobník | | +| 6F | PUSH16 | 3 | `.` | `uint128` | | vložit 16bajtovou hodnotu na zásobník | | +| 70 | PUSH17 | 3 | `.` | `uint136` | | vložit 17bajtovou hodnotu na zásobník | | +| 71 | PUSH18 | 3 | `.` | `uint144` | | vložit 18bajtovou hodnotu na zásobník | | +| 72 | PUSH19 | 3 | `.` | `uint152` | | vložit 19bajtovou hodnotu na zásobník | | +| 73 | PUSH20 | 3 | `.` | `uint160` | | vložit 20bajtovou hodnotu na zásobník | | +| 74 | PUSH21 | 3 | `.` | `uint168` | | vložit 21bajtovou hodnotu na zásobník | | +| 75 | PUSH22 | 3 | `.` | `uint176` | | vložit 22bajtovou hodnotu na zásobník | | +| 76 | PUSH23 | 3 | `.` | `uint184` | | vložit 23bajtovou hodnotu na zásobník | | +| 77 | PUSH24 | 3 | `.` | `uint192` | | vložit 24bajtovou hodnotu na zásobník | | +| 78 | PUSH25 | 3 | `.` | `uint200` | | vložit 25bajtovou hodnotu na zásobník | | +| 79 | PUSH26 | 3 | `.` | `uint208` | | vložit 26bajtovou hodnotu na zásobník | | +| 7A | PUSH27 | 3 | `.` | `uint216` | | vložit 27bajtovou hodnotu na zásobník | | +| 7B | PUSH28 | 3 | `.` | `uint224` | | vložit 28bajtovou hodnotu na zásobník | | +| 7C | PUSH29 | 3 | `.` | `uint232` | | vložit 29bajtovou hodnotu na zásobník | | +| 7D | PUSH30 | 3 | `.` | `uint240` | | vložit 30bajtovou hodnotu na zásobník | | +| 7E | PUSH31 | 3 | `.` | `uint248` | | vložit 31bajtovou hodnotu na zásobník | | +| 7F | PUSH32 | 3 | `.` | `uint256` | | vložit 32bajtovou hodnotu na zásobník | | +| 80 | DUP1 | 3 | `a` | `a, a` | | klonovat 1. hodnotu na zásobníku | | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | klonovat 2. hodnotu na zásobníku | | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | klonovat 3. hodnotu na zásobníku | | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | klonovat 4. hodnotu na zásobníku | | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | klonovat 5. hodnotu na zásobníku | | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | klonovat 6. hodnotu na zásobníku | | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | klonovat 7. hodnotu na zásobníku | | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | klonovat 8. hodnotu na zásobníku | | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | klonovat 9. hodnotu na zásobníku | | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | klonovat 10. hodnotu na zásobníku | | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | klonovat 11. hodnotu na zásobníku | | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | klonovat 12. hodnotu na zásobníku | | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | klonovat 13. hodnotu na zásobníku | | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | klonovat 14. hodnotu na zásobníku | | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | klonovat 15. hodnotu na zásobníku | | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | klonovat 16. hodnotu na zásobníku | | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | | +| A5-EF | _neplatné_ | | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | plyn, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | stejné jako DELEGATECALL, ale nešíří původní msg.sender a msg.value | | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | vrátit mem[ost:ost+len-1] | | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | | +| F6-F9 | _neplatné_ | | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `plyn, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | | +| FB-FC | _neplatné_ | | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | označený neplatný operační kód – [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | pošle všechny ETH na `addr`; pokud je proveden ve stejné transakci, ve které byla vytvořena smlouva, smlouvu zničí | | diff --git a/public/content/translations/cs/developers/docs/frameworks/index.md b/public/content/translations/cs/developers/docs/frameworks/index.md new file mode 100644 index 00000000000..cd02dfca5cd --- /dev/null +++ b/public/content/translations/cs/developers/docs/frameworks/index.md @@ -0,0 +1,157 @@ +--- +title: "Frameworky pro vývoj dappek" +description: "Prozkoumejte výhody frameworků a porovnejte dostupné možnosti." +lang: cs +--- + +## Úvod do frameworků {#introduction-to-frameworks} + +Vytvoření plnohodnotné dappky (decentralizované aplikace) vyžaduje +různé technologie. Softwarové frameworky zahrnují mnoho potřebných +funkcí nebo poskytují snadné pluginové systémy, které vám umožní vybrat si nástroje, +které potřebujete. + +Frameworky nabízejí velké množství funkcí, +například: + +- Funkce ke spuštění vlastního lokálního blockchainu. +- Nástroje pro kompilaci a testování chytrých kontraktů. +- Vývojové doplňky klienta, které vytvoří vaši uživatelskou aplikaci + v rámci stejného projektu/úložiště. +- Konfigurace pro připojení k sítím Ethereum a nasazení + kontraktů, ať už na lokálně spuštěnou instanci, nebo na jednu z + veřejných sítí Ethereum. +- Decentralizovaná distribuce aplikací – integrace s možnostmi úložiště, + jako je IPFS. + +## Předpoklady {#prerequisites} + +Než se ponoříte do frameworků, doporučujeme vám nejprve si přečíst náš úvod do [dapps](/developers/docs/dapps/) a [zásobníku Ethereum](/developers/docs/ethereum-stack/). + +## Dostupné frameworky {#available-frameworks} + +**Foundry** – **_Foundry je bleskově rychlá, přenosná a modulární sada nástrojů pro vývoj aplikací na Ethereum_** + +- [Nainstalovat Foundry](https://book.getfoundry.sh/) +- [Kniha o Foundry](https://book.getfoundry.sh/) +- [Komunitní chat Foundry na Telegramu](https://t.me/foundry_support) +- [Awesome Foundry](https://github.com/crisgarner/awesome-foundry) + +**Hardhat –** **_Vývojové prostředí Ethereum pro profesionály._** + +- [hardhat.org](https://hardhat.org) +- [GitHub](https://github.com/nomiclabs/hardhat) + +**Ape –** **_Nástroj pro vývoj chytrých kontraktů pro pythonisty, datové vědce a bezpečnostní profesionály._** + +- [Dokumentace](https://docs.apeworx.io/ape/stable/) +- [GitHub](https://github.com/ApeWorX/ape) + +**Web3j –** **_Platforma pro vývoj blockchainových aplikací na JVM._** + +- [Domovská stránka](https://www.web3labs.com/web3j-sdk) +- [Dokumentace](https://docs.web3j.io) +- [GitHub](https://github.com/web3j/web3j) + +**ethers-kt –** **_Asynchronní, vysoce výkonná knihovna pro Kotlin/Javu/Android pro blockchainy založené na EVM._** + +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [Příklady](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Create Eth App –** **_Vytvořte aplikace s podporou Ethereum jedním příkazem. Nabízí širokou škálu UI frameworků a DeFi šablon._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) +- [Šablony](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) + +**Scaffold-Eth –** **_Ethers.js + Hardhat + React komponenty a hooky pro web3: vše, co potřebujete k tomu, abyste mohli začít budovat decentralizované aplikace využívající chytré kontrakty._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) + +**Tenderly –** **_Web3 vývojářská platforma, která umožňuje blockchainovým vývojářům vytvářet, testovat, ladit, monitorovat a provozovat chytré kontrakty a zlepšovat UX pro dapps._** + +- [Webová stránka](https://tenderly.co/) +- [Dokumentace](https://docs.tenderly.co/) + +**The Graph –** **_The Graph pro efektivní dotazování na data z blockchainu._** + +- [Webová stránka](https://thegraph.com/) +- [Návod](/developers/tutorials/the-graph-fixing-web3-data-querying/) + +**Alchemy –** **_Vývojářská platforma pro Ethereum._** + +- [alchemy.com](https://www.alchemy.com/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**NodeReal –** **_Vývojářská platforma pro Ethereum._** + +- [Nodereal.io](https://nodereal.io/) +- [GitHub](https://github.com/node-real) +- [Discord](https://discord.gg/V5k5gsuE) + +**thirdweb SDK –** **_Vytvářejte web3 aplikace, které mohou interagovat s vašimi chytrými kontrakty pomocí našich výkonných SDK a CLI._** + +- [Dokumentace](https://portal.thirdweb.com/sdk/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Chainstack –** **_Vývojářská platforma pro Web3 (Ethereum a další)._** + +- [chainstack.com](https://www.chainstack.com/) +- [GitHub](https://github.com/chainstack) +- [Discord](https://discord.gg/BSb5zfp9AT) + +**Crossmint –** **_Web3 vývojářská platforma podnikové úrovně, která vám umožňuje vytvářet NFT aplikace na všech hlavních EVM řetězcích (a dalších)._** + +- [Webová stránka](https://www.crossmint.com) +- [Dokumentace](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +**Brownie –** **_Vývojové prostředí a testovací framework založený na Pythonu._** + +- [Dokumentace](https://eth-brownie.readthedocs.io/en/latest/) +- [GitHub](https://github.com/eth-brownie/brownie) +- **Brownie se v současné době neudržuje** + +**OpenZeppelin SDK –** **_Kompletní sada nástrojů pro chytré kontrakty: sada nástrojů, které vám pomohou vyvíjet, kompilovat, vylepšovat, nasazovat chytré kontrakty a pracovat s nimi._** + +- [OpenZeppelin Defender SDK](https://docs.openzeppelin.com/defender/sdk) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) +- [Komunitní fórum](https://forum.openzeppelin.com/c/support/17) +- **Vývoj OpenZeppelin SDK byl ukončen** + +**Catapulta –** **_Nástroj pro nasazování chytrých kontraktů na více řetězců, který automatizuje ověřování v prohlížečích bloků, sleduje nasazené chytré kontrakty, sdílí zprávy o nasazení a funguje jako plug-n-play pro projekty Foundry a Hardhat._** + +- [Webová stránka](https://catapulta.sh/) +- [Dokumentace](https://catapulta.sh/docs) +- [Github](https://github.com/catapulta-sh) + +**GoldRush (využívá Covalent) –** **_GoldRush nabízí nejkomplexnější sadu API pro data z blockchainu pro vývojáře, analytiky a podniky. Ať už vytváříte DeFi dashboard, peněženku, obchodního bota, AI agenta nebo platformu pro dodržování předpisů, datová API poskytují rychlý, přesný a pro vývojáře přívětivý přístup k základním onchain datům, která potřebujete_** + +- [Webová stránka](https://goldrush.dev/) +- [Dokumentace](https://goldrush.dev/docs/chains/ethereum) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + +**Wake –** **_Univerzální pythonový framework pro testování kontraktů, fuzzing, nasazení, skenování zranitelností a navigaci v kódu._** + +- [Domovská stránka](https://getwake.io/) +- [Dokumentace](https://ackeeblockchain.com/wake/docs/latest/) +- [GitHub](https://github.com/Ackee-Blockchain/wake) +- [Rozšíření pro VS Code](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) + +**Veramo –** **_Otevřený, modulární a agnostický framework, který usnadňuje vývojářům decentralizovaných aplikací vytvářet decentralizované identity a ověřitelná pověření ve svých aplikacích._** + +- [Domovská stránka](https://veramo.io/) +- [Dokumentace](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [Balíček NPM](https://www.npmjs.com/package/@veramo/core) + +## Další čtení {#further-reading} + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ + +## Související témata {#related-topics} + +- [Nastavení lokálního vývojového prostředí](/developers/local-environment/) diff --git a/public/content/translations/cs/developers/docs/gas/index.md b/public/content/translations/cs/developers/docs/gas/index.md index 90a371cc64f..c4c6e4c1c15 100644 --- a/public/content/translations/cs/developers/docs/gas/index.md +++ b/public/content/translations/cs/developers/docs/gas/index.md @@ -1,7 +1,7 @@ --- title: Palivo a poplatky metaTitle: "Palivo a poplatky na Ethereu: technický přehled" -description: +description: "Zjistěte více o poplatcích za palivo na Ethereu, jak se vypočítávají a jakou roli hrají v zabezpečení sítě a zpracování transakcí." lang: cs --- @@ -9,7 +9,7 @@ Palivo je pro síť Ethereum nezbytné. Umožňuje jí fungovat, stejně jako au ## Předpoklady {#prerequisites} -Abyste lépe porozuměli této stránce, doporučujeme vám si nejprve přečíst o [transakcích](/developers/docs/transactions/) a [EVM](/developers/docs/evm/). +Pro lepší pochopení této stránky vám doporučujeme si nejprve přečíst o [transakcích](/developers/docs/transactions/) a [EVM](/developers/docs/evm/). ## Co je to palivo? {#what-is-gas} @@ -17,15 +17,16 @@ Palivo označuje jednotku, která měří množství výpočetního úsilí pot Jelikož každá transakce na Ethereu potřebuje výpočetní zdroje k jejímu provedení, tyto zdroje se musí zaplatit, aby Ethereum nebylo zranitelné vůči spamovým útokům a nemohlo se zaseknout v nekonečných výpočetních smyčkách. Platba za výpočetní úsilí se provádí ve formě poplatku za palivo. -Poplatek za palivo je **množství paliva použitého k provedení určité operace, vynásobené nákladem na jednotku paliva**. Poplatek je zaplacen bez ohledu na to, zda je transakce úspěšně realizována, nebo selže. +Poplatek za palivo je **množství paliva použitého k provedení určité operace vynásobené cenou za jednotku paliva**. Poplatek je zaplacen bez ohledu na to, zda je transakce úspěšně realizována, nebo selže. -![Diagram znázorňující, kde je potřeba palivo pro EVM operace](./gas.png) _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram znázorňující, kde je v operacích EVM zapotřebí palivo](./gas.png) +_Diagram převzat z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ Poplatky za palivo musí být zaplaceny v nativní měně Etherea, etheru (ETH). Ceny paliva jsou obvykle uváděny v gwei, což je denominace ETH. Každý gwei je roven jedné miliardtině ETH (0,000000001 ETH nebo 10-9 ETH). Např. místo toho, abyste řekli, že vaše palivo stojí 0,000000001 etheru, můžete říct, že stojí 1 gwei. -Slovo 'gwei' je zkratka pro „giga-wei“, což znamená „miliarda wei“. Jeden gwei se rovná jedné miliardě wei. Wei samo o sobě (pojmenované po [Wei Daiovi](https://wikipedia.org/wiki/Wei_Dai), tvůrci [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) je nejmenší jednotkou ETH. +Slovo 'gwei' je zkratka pro „giga-wei“, což znamená „miliarda wei“. Jeden gwei se rovná jedné miliardě wei. Samotný wei (pojmenovaný po [Wei Daiovi](https://wikipedia.org/wiki/Wei_Dai), tvůrci [b-money](https://www.investopedia.com/terms/b/bmoney.asp)) je nejmenší jednotkou ETH. ## Jak se vypočítají palivové poplatky? {#how-are-gas-fees-calculated} @@ -35,7 +36,7 @@ Celkový poplatek za palivo, který zaplatíte, se skládá ze dvou složek: `z `Základní poplatek` stanovuje protokol – musíte zaplatit alespoň tuto částku, aby byla vaše transakce považována za platnou. `Prioritní poplatek` je spropitné, které přidáte k základnímu poplatku, aby byla vaše transakce atraktivní pro validátory – aby ji vybrali k zařazení do dalšího bloku. -Transakce, která nabízí pouze `základní poplatek`, je technicky platná, ale je nepravděpodobné, že bude do bloku zařazena, protože nenabízí validátorům žádný motiv ji vybrat před jakoukoli jinou transakcí. „Správný“ `prioritní` poplatek je stanoven podle využití sítě v době odeslání vaší transakce – pokud je vysoká poptávka, možná budete muset nastavit vyšší `prioritní` poplatek, ale když je poptávka nižší, můžete zaplatit méně. +Transakce, u které se platí pouze `základní poplatek`, je technicky platná, ale je nepravděpodobné, že bude zahrnuta, protože validátorům nenabízí žádnou motivaci, aby ji upřednostnili před jinou transakcí. „Správný“ `prioritní` poplatek je určen vytížením sítě v době odeslání transakce – pokud je velká poptávka, možná budete muset nastavit vyšší `prioritní` poplatek, ale když je poptávka nižší, můžete zaplatit méně. Např. řekněme, že Jordan musí zaplatit Taylorovi 1 ETH. Převod ETH vyžaduje 21 000 jednotek paliva a základní poplatek je 10 gwei. Jordan přidá spropitné 2 gwei. @@ -43,44 +44,44 @@ Celkový poplatek by nyní dělal: `spotřebované jednotky paliva * (základní poplatek + prioritní poplatek)` -kde `základní poplatek` je hodnota stanovená protokolem a `prioritní poplatek` je hodnota stanovená uživatelem jako spropitné pro validátora. +kde `základní poplatek` je hodnota stanovená protokolem a `prioritní poplatek` je hodnota, kterou stanoví uživatel jako spropitné pro validátora. -tj. `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH). +např. `21,000 * (10 + 2) = 252,000 gwei` (0,000252 ETH). -Když Jordan odešle peníze, z jeho účtu bude odečteno 1,000252 ETH. Taylor obdrží 1,0000 ETH. Validátor obdrží spropitné ve výši 0,000042 ETH. `Základní poplatek` 0,00021 ETH bude spálen. +Když Jordan odešle peníze, z jeho účtu bude odečteno 1,000252 ETH. Taylor obdrží 1,0000 ETH. Validátor obdrží spropitné ve výši 0,000042 ETH. `Základní poplatek` ve výši 0,00021 ETH je spálen. ### Základní poplatek {#base-fee} -Každý blok má základní poplatek, který funguje jako rezervní cena. Aby byla transakce způsobilá k zařazení do bloku, nabízená cena za palivo musí být rovna alespoň základnímu poplatku. Základní poplatek je vypočítán nezávisle na aktuálním bloku a je místo toho určen bloky před ním – což dělá transakční poplatky pro uživatele předvídatelnějšími. Po vytvoření bloku je tento **základní poplatek „spálen“**, což znamená, že množství etheru použité na jeho zaplacení je odstraněno z oběhu. +Každý blok má základní poplatek, který funguje jako rezervní cena. Aby byla transakce způsobilá k zařazení do bloku, nabízená cena za palivo musí být rovna alespoň základnímu poplatku. Základní poplatek se vypočítává nezávisle na aktuálním bloku a je určen bloky před ním, díky čemuž jsou transakční poplatky pro uživatele předvídatelnější. Při vytvoření bloku je tento **základní poplatek „spálen“**, čímž je odstraněn z oběhu. -Základní poplatek je vypočítán podle vzorce, který porovnává velikost předchozího bloku (množství paliva použitého na všechny transakce) s cílovou velikostí. Základní poplatek se zvýší o maximálně 12,5 % za blok, pokud je překročena cílová velikost bloku. Tento exponenciální růst činí ekonomicky neudržitelným, aby velikost bloku zůstala vysoká po neomezenou dobu. +Základní poplatek se vypočítává podle vzorce, který porovnává velikost předchozího bloku (množství paliva spotřebovaného na všechny transakce) s cílovou velikostí (polovina limitu transakčních poplatků). Základní poplatek se zvýší nebo sníží o maximálně 12,5 % za blok, pokud je cílová velikost bloku překročena, resp. nedosažena. Tento exponenciální růst činí ekonomicky neudržitelným, aby velikost bloku zůstala vysoká po neomezenou dobu. -| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek | -| ----------- | ---------------:| ----------------:| --------------------------:| -| 1 | 15M | 0% | 100 gwei | -| 2 | 30M | 0% | 100 gwei | -| 3 | 30M | 12,5 % | 112,5 gwei | -| 4 | 30M | 12,5 % | 126,6 gwei | -| 5 | 30M | 12,5 % | 142,4 gwei | -| 6 | 30M | 12,5 % | 160,2 gwei | -| 7 | 30M | 12,5 % | 180,2 gwei | -| 8 | 30M | 12,5 % | 202,7 gwei | +| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek | +| ----------- | ----------------------: | ---------------: | -------------------------: | +| 1 | 18 mil. | 0% | 100 gwei | +| 2 | 36 mil. | 0% | 100 gwei | +| 3 | 36 mil. | 12,5 % | 112,5 gwei | +| 4 | 36 mil. | 12,5 % | 126,6 gwei | +| 5 | 36 mil. | 12,5 % | 142,4 gwei | +| 6 | 36 mil. | 12,5 % | 160,2 gwei | +| 7 | 36 mil. | 12,5 % | 180,2 gwei | +| 8 | 36 mil. | 12,5 % | 202,7 gwei | -Podle výše uvedené tabulky by k vytvoření transakce v bloku číslo 9 peněženka s jistotou informovala uživatele, že **maximální základní poplatek** dalšího bloku je `aktuální základní poplatek * 112,5 %` nebo `202,7 gwei * 112,5 % = 228,1 gwei`. +Ve výše uvedené tabulce je uveden příklad s limitem transakčních poplatků 36 milionů. Podle tohoto příkladu při vytváření transakce v bloku číslo 9 peněženka s jistotou informuje uživatele, že **maximální základní poplatek**, který bude přidán do dalšího bloku, je `current base fee * 112.5%` neboli `202.7 gwei * 112.5% = 228.1 gwei`. Je také důležité poznamenat, že z důvodu rychlosti, s jakou se základní poplatek zvyšuje předcházejícímu plnému bloku, je nepravděpodobné, že bychom viděli dlouhodobé peaky plných bloků. -| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek | -| ----------- | ---------------:| ----------------:| --------------------------:| -| 30 | 30M | 12,5 % | 2 705,6 gwei | -| ... | ... | 12,5 % | ... | -| 50 | 30M | 12,5 % | 28 531,3 gwei | -| ... | ... | 12,5 % | ... | -| 100 | 30M | 12,5 % | 10 302 608,6 gwei | +| Číslo bloku | Zahrnuté palivo | Zvýšení poplatku | Aktuální základní poplatek | +| --------------------------------------------------- | --------------------------------------------------: | ---------------: | --------------------------------------------------: | +| 30 | 36 mil. | 12,5 % | 2 705,6 gwei | +| ... | ... | 12,5 % | ... | +| 50 | 36 mil. | 12,5 % | 28 531,3 gwei | +| ... | ... | 12,5 % | ... | +| 100 | 36 mil. | 12,5 % | 10 302 608,6 gwei | ### Prioritní poplatek (spropitné) {#priority-fee} -Prioritní poplatek (spropitné) motivuje validátory k zařazení transakce do bloku. Bez spropitného by pro validátory bylo ekonomicky výhodné těžit prázdné bloky, protože by obdrželi stejnou odměnu za blok. Malé spropitné dává validátorům minimální motivaci zahrnout transakci. Pro transakce, které mají být preferenčně provedeny před jinými transakcemi ve stejném bloku, lze přidat vyšší spropitné a pokusit se tak přeplatit konkurenční transakce. +Prioritní poplatek (spropitné) motivuje validátory, aby maximalizovali počet transakcí v bloku, přičemž jsou omezeni pouze limitem transakčních poplatků bloku. Bez spropitného by racionální validátor mohl zahrnout méně transakcí, nebo dokonce žádné, a to bez jakéhokoli přímého postihu na exekuční nebo konsensuální vrstvě, protože odměny ze stakingu jsou nezávislé na počtu transakcí v bloku. Spropitné navíc umožňuje uživatelům přeplatit ostatní za prioritu v rámci stejného bloku, čímž efektivně signalizují naléhavost. ### Maximální poplatek {#maxfee} @@ -88,7 +89,11 @@ Při provedení transakce na síti mohou uživatelé specifikovat maximální li ### Velikost bloku {#block-size} -Každý blok má cílovou velikost 15 milionů jednotek paliva, ale velikost bloků se bude zvyšovat nebo snižovat v závislosti na poptávce na síti, až do limitu bloku 30 milionů jednotek paliva (2x cílová velikost bloku). Protokol v průměru dosahuje rovnovážné velikosti bloku 15 milionů prostřednictvím procesu zvaného _tâtonnement_. To znamená, že pokud je velikost bloku větší než cílová velikost bloku, protokol zvýší základní poplatek pro následující blok. Podobně, pokud je velikost bloku menší než cílová velikost, protokol sníží základní poplatek. Hodnota, o kterou se základní poplatek upravuje, je úměrná tomu, jak daleko je aktuální velikost bloku od cíle. [Další informace o blocích](/developers/docs/blocks/). +Každý blok má cílovou velikost poloviny současného limitu transakčních poplatků, ale velikost bloků se bude zvyšovat nebo snižovat v souladu s poptávkou v síti, a to až do dosažení limitu bloku (2x cílová velikost bloku). Protokol dosahuje rovnovážné průměrné velikosti bloku na cílové úrovni prostřednictvím procesu _tâtonnement_. To znamená, že pokud je velikost bloku větší než cílová velikost bloku, protokol zvýší základní poplatek pro následující blok. Podobně, pokud je velikost bloku menší než cílová velikost, protokol sníží základní poplatek. + +Hodnota, o kterou se základní poplatek upravuje, je úměrná tomu, jak daleko je aktuální velikost bloku od cíle. Jedná se o lineární výpočet od -12,5 % pro prázdný blok, 0 % při cílové velikosti, až po +12,5 % pro blok, který dosáhne limitu transakčních poplatků. Limit transakčních poplatků se může v čase měnit na základě signalizace validátorů a také prostřednictvím vylepšení sítě. Změny limitu transakčních poplatků v čase si můžete [prohlédnout zde](https://eth.blockscout.com/stats/averageGasLimit?interval=threeMonths). + +[Více o blocích](/developers/docs/blocks/) ### Výpočet poplatků za palivo v praxi {#calculating-fees-in-practice} @@ -98,13 +103,14 @@ Můžete explicitně uvést, kolik jste ochotni zaplatit, aby byla vaše transak Stručně řečeno, poplatky za palivo pomáhají udržovat bezpečnost sítě Ethereum. Požadováním poplatku za každý výpočet provedený v síti zabráníme nečestným aktérům v zahlcení sítě. Abychom se vyhnuli náhodným nebo záměrným nekonečným smyčkám nebo jinému plýtvání výpočetními zdroji v kódu, každá transakce musí nastavit limit na počet výpočetních kroků potřebných k vykonání kódu. Základní jednotkou výpočtu je „palivo“. -Ačkoliv transakce obsahuje limit, palivo nevyužité během transakce se vrací uživateli (tj. `maximální poplatek - (základní polatek + spropitné)` se vrací). +Ačkoli transakce zahrnuje limit, jakékoli palivo, které se v transakci nespotřebuje, se vrací uživateli (např. se vrací `max fee - (base fee + tip)`). -![Diagram ukazující vrácení nepoužitého paliva](../transactions/gas-tx.png) _Schéma převzato z [ilustrace Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ +![Diagram znázorňující, jak se vrací nespotřebované palivo](../transactions/gas-tx.png) +_Diagram převzat z [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ ## Co je to limit paliva? {#what-is-gas-limit} -Limit paliva označuje maximální množství paliva, které jste ochotni za transakci utratit. Složitější transakce zahrnující [chytré kontrakty](/developers/docs/smart-contracts/) potřebují více výpočetního výkonu, a proto vyžadují vyšší limit paliva než jednoduchá platba. Standardní převod ETH vyžaduje limit paliva 21 000 jednotek. +Limit paliva označuje maximální množství paliva, které jste ochotni za transakci utratit. Složitější transakce zahrnující [chytré kontrakty](/developers/docs/smart-contracts/) vyžadují více výpočetní práce, takže vyžadují vyšší limit transakčních poplatků než jednoduchá platba. Standardní převod ETH vyžaduje limit paliva 21 000 jednotek. Např. pokud nastavíte limit paliva na 50 000 pro jednoduchý převod ETH, EVM spotřebuje 21 000 a zbývajících 29 000 se vám vrátí. Pokud však zadáte příliš málo paliva, například limit paliva 20 000 pro jednoduchý převod ETH, transakce ve fázi validace selže. Bude odmítnuta před zařazením do bloku a nebude spotřebováno žádné palivo. Na druhou stranu, pokud transakci během provádění dojde palivo (např. chytrý kontrakt spotřebuje v polovině provádění veškeré palivo), EVM vrátí všechny změny, ale veškeré poskytnuté palivo bude stále spotřebováno na provedenou práci. @@ -114,28 +120,32 @@ Vysoké poplatky za palivo jsou způsobeny popularitou Etherea. Pokud je poptáv ## Iniciativy na snížení nákladů na palivo {#initiatives-to-reduce-gas-costs} -[Vylepšení škálovatelnosti](/roadmap/) Etherea by měly řešit některé problémy palivových poplatků, což následně umožní platformě zpracovávat tisíce transakcí za sekundu a škálovat globálně. +[Vylepšení škálovatelnosti](/roadmap/) Etherea by měla v konečném důsledku vyřešit některé problémy s poplatky za palivo, což platformě umožní zpracovávat tisíce transakcí za sekundu a škálovat globálně. + +Primární iniciativou ke snížení palivových nákladů a zlepšení uživatelských možností a škálovatelnosti je škálování druhé vrstvy. -Primární iniciativou ke snížení palivových nákladů a zlepšení uživatelských možností a škálovatelnosti je škálování druhé vrstvy. [Další informace o škálování druhé vrstvy](/developers/docs/scaling/#layer-2-scaling). +[Více o škálování na druhé vrstvě](/developers/docs/scaling/#layer-2-scaling) ## Monitorování poplatků za palivo {#monitoring-gas-fees} Pokud chcete monitorovat poplatky za palivo, abyste mohli odesílat své ETH za nižší ceny, můžete využít několik různých nástrojů, např.: -- [Etherscan](https://etherscan.io/gastracker) – _odhad ceny paliva za transakci_ -- [ETH tracker paliva](https://www.ethgastracker.com/) _Monitorujte a sledujte ceny paliva na Ethereu a vrstvě 2, abyste snížili transakční poplatky a ušetřili peníze_ -- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) – _rozšíření pro prohlížeč Chrome odhadující poplatky za palivo, které podporuje jak typ 0 legacy transakce, tak typ 2 transakce EIP-1559_ -- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) – _kalkulačka poplatků za palivo v místní měně pro různé typy transakcí na hlavní síti, Arbitru a Polygonu_ +- [Etherscan](https://etherscan.io/gastracker) _Odhad ceny transakčního paliva_ +- [Blockscout](https://eth.blockscout.com/gas-tracker) _Open-source odhad ceny transakčního paliva_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _Monitorujte a sledujte ceny paliva na Ethereu a L2, abyste snížili transakční poplatky a ušetřili peníze_ +- [Blocknative ETH Gas Estimator](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Rozšíření pro Chrome pro odhad paliva, které podporuje jak starší transakce typu 0, tak transakce typu 2 EIP-1559._ +- [Cryptoneur Gas Fees Calculator](https://www.cryptoneur.xyz/gas-fees-calculator) _Vypočítejte poplatky za palivo ve vaší místní měně pro různé typy transakcí na hlavní síti (Mainnet), Arbitrum a Polygonu._ ## Související nástroje {#related-tools} -- [Blocknative's Gas Platform](https://www.blocknative.com/gas) – _API pro odhadování poplatků za palivo podporované globální datovou platformou Blocknative mempool_ +- [Blocknative's Gas Platform](https://www.blocknative.com/gas) _API pro odhadování paliva, které využívá globální datovou platformu mempoolu od Blocknative_ +- [Gas Network](https://gas.network) Oracles pro palivo na blockchainu. Podpora pro více než 35 chainů. -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Vysvětlení paliva na Ethereu](https://defiprime.com/gas) -- [Snížení spotřeby paliva ve vašich chytrých kontraktech](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [Vysvětlení ethereového paliva](https://defiprime.com/gas) +- [Snížení spotřeby paliva vašich chytrých kontraktů](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) - [Strategie optimalizace paliva pro vývojáře](https://www.alchemy.com/overviews/solidity-gas-optimization) -- [Dokumentace EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) -- [Zdroje k EIP-1559 od Tima Beika](https://hackmd.io/@timbeiko/1559-resources) -- [EIP-1559: Oddělování mechanismů od memů](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) +- [Dokumentace k EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). +- [Zdroje Tima Beika k EIP-1559](https://hackmd.io/@timbeiko/1559-resources) +- [EIP-1559: Oddělení mechanismů od memů](https://web.archive.org/web/20241126205908/https://research.2077.xyz/eip-1559-separating-mechanisms-from-memes) diff --git a/public/content/translations/cs/developers/docs/ides/index.md b/public/content/translations/cs/developers/docs/ides/index.md new file mode 100644 index 00000000000..016ccc0ac00 --- /dev/null +++ b/public/content/translations/cs/developers/docs/ides/index.md @@ -0,0 +1,64 @@ +--- +title: "Integrovaná vývojová prostředí (IDE)" +description: "Přečtěte si o webových a desktopových IDE pro vývoj na Ethereu, včetně Remixu, VS Code a oblíbených pluginů." +lang: cs +--- + +Při nastavování [integrovaného vývojového prostředí (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) je programování aplikací na Ethereu podobné jako programování jakéhokoli jiného softwarového projektu. Existuje spousta možností, takže si na konci dne vyberte IDE nebo kódový editor, který nejlépe vyhovuje vašim preferencím. S největší pravděpodobností bude nejlepší volbou IDE, které již používáte pro vývoj tradičního softwaru. + +## Webová IDE {#web-based-ides} + +Pokud si chcete pohrát s kódem před tím, než si [nastavíte lokální vývojové prostředí](/developers/local-environment/), tyto webové aplikace jsou speciálně vytvořeny pro vývoj chytrých kontraktů na Ethereu. + +**[Remix](https://remix.ethereum.org/)** - **_Webové IDE s vestavěnou statickou analýzou a testovacím blockchainovým virtuálním strojem_** + +- [Dokumentace](https://remix-ide.readthedocs.io/en/latest/#) +- [Gitter](https://gitter.im/ethereum/remix) + +**[ChainIDE](https://chainide.com/)** - **_Cloudové IDE pro více blockchainů_** + +- [Dokumentace](https://chainide.gitbook.io/chainide-english-1/) +- [Fórum nápovědy](https://forum.chainide.com/) + +**[Replit (Solidity Starter - Beta)](https://replit.com/@replit/Solidity-starter-beta)** - **_Přizpůsobitelné vývojové prostředí pro Ethereum s hot-reloadingem, kontrolou chyb a prvotřídní podporou testnetu_** + +- [Dokumentace](https://docs.replit.com/) + +**[Tenderly Sandbox](https://sandbox.tenderly.co/)** - **_Rychlé prototypovací prostředí, kde můžete psát, spouštět a ladit chytré kontrakty v prohlížeči pomocí Solidity a JavaScriptu_** + +**[EthFiddle](https://ethfiddle.com/)** - **_Webové IDE, které vám umožní psát, kompilovat a ladit váš chytrý kontrakt_** + +- [Gitter](https://gitter.im/loomnetwork/ethfiddle) + +## Desktopová IDE {#desktop-ides} + +Většina zavedených IDE má vytvořené pluginy pro zlepšení vývojového prostředí pro Ethereum. Minimálně poskytují zvýrazňování syntaxe pro [jazyky chytrých kontraktů](/developers/docs/smart-contracts/languages/). + +**Visual Studio Code -** **_Profesionální multiplatformní IDE s oficiální podporou Etherea_** + +- [Visual Studio Code](https://code.visualstudio.com/) +- [Ukázky kódu](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [GitHub](https://github.com/microsoft/vscode) + +**JetBrains IDEs (IntelliJ IDEA, atd.) -** **_Základní nástroje pro vývojáře softwaru a týmy_** + +- [JetBrains](https://www.jetbrains.com/) +- [GitHub](https://github.com/JetBrains) +- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) + +**Remix Desktop -** **_Remix IDE na vašem lokálním počítači_** + +- [Stáhnout](https://github.com/ethereum/remix-desktop/releases) +- [GitHub](https://github.com/ethereum/remix-desktop) + +## Pluginy a rozšíření {#plugins-extensions} + +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) – Jazyk Ethereum Solidity pro Visual Studio Code +- [Solidity + Hardhat pro VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) – Podpora pro Solidity a Hardhat od týmu Hardhat +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) – Formátovač kódu využívající Prettier + +## Další čtení {#further-reading} + +- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _– Seznam Ethereum IDE od Alchemy_ + +_Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ diff --git a/public/content/translations/cs/developers/docs/index.md b/public/content/translations/cs/developers/docs/index.md index 44c82d43f8a..8d20727b83c 100644 --- a/public/content/translations/cs/developers/docs/index.md +++ b/public/content/translations/cs/developers/docs/index.md @@ -1,14 +1,14 @@ --- -title: Dokumentace pro vývoj na Ethereu -description: Představení vývojářské dokumentace na ethereum.org. +title: "Dokumentace pro vývoj na Ethereu" +description: "Představení vývojářské dokumentace na ethereum.org." lang: cs --- Tato dokumentace je navržena tak, aby vám pomohla s vývojem na Ethereu. Pokrývá Ethereum jako koncept, vysvětluje technologický stack Etherea a dokumentuje pokročilá témata pro složitější aplikace a případy použití. -Jedná se o komunitní open-source projekt, takže neváhejte navrhovat nová témata, přidávat nový obsah a poskytovat příklady tam, kde si myslíte, že by to mohlo být užitečné. Veškerou dokumentaci lze upravovat přes GitHub – pokud si nejste jisti, jak na to, [postupujte podle těchto pokynů](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). +Jedná se o komunitní open-source projekt, takže neváhejte navrhovat nová témata, přidávat nový obsah a poskytovat příklady tam, kde si myslíte, že by to mohlo být užitečné. Veškerou dokumentaci lze upravit prostřednictvím GitHubu – pokud si nejste jisti, jak na to, [postupujte podle těchto pokynů](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). -## Moduly vývoje {#development-modules} +## Vývojové moduly {#development-modules} Pokud je toto váš první pokus o vývoj na Ethereu, doporučujeme začít od začátku a postupovat jako při čtení knihy. @@ -16,10 +16,10 @@ Pokud je toto váš první pokus o vývoj na Ethereu, doporučujeme začít od z -### Ethereum zásobník {#ethereum-stack} +### Stack Etherea {#ethereum-stack} -### Další {#advanced} +### Pokročilé {#advanced} diff --git a/public/content/translations/cs/developers/docs/intro-to-ether/index.md b/public/content/translations/cs/developers/docs/intro-to-ether/index.md index f877b92093f..a5d26126305 100644 --- a/public/content/translations/cs/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/cs/developers/docs/intro-to-ether/index.md @@ -1,12 +1,12 @@ --- -title: Úvod ke kryptoměně ether -description: Úvod ke kryptoměně ether pro vývojáře. +title: "Technický úvod do etheru" +description: "Úvod ke kryptoměně ether pro vývojáře." lang: cs --- ## Předpoklady {#prerequisites} -K lepšímu pochopení této stránky vám doporučujeme si nejprve přečíst náš [úvod do Etherea](/developers/docs/intro-to-ethereum/). +Pro lepší porozumění této stránce vám doporučujeme si nejprve přečíst [Úvod do Etherea](/developers/docs/intro-to-ethereum/). ## Co je kryptoměna? {#what-is-a-cryptocurrency} @@ -16,17 +16,17 @@ Médium směny je cokoliv, co je široce přijímáno jako platba za zboží a s První kryptoměnou byl Bitcoin, který vytvořil Satoshi Nakamoto. Od spuštění Bitcoinu v roce 2009 lidé vytvořili tisíce kryptoměn na různých blockchainech. -## Co je Ether? {#what-is-ether} +## Co je to ether? {#what-is-ether} -**Ether (ETH)** je kryptoměna používaná pro různé účely v síti Ethereum. V základu je to jediná přijatelná forma platby za transakční poplatky a po [Sloučení](/roadmap/merge) je ether vyžadován k validaci a navrhování bloků na hlavní síti. Ether se také používá jako primární forma zajištění na [DeFi](/defi) půjčkových trzích, jako účetní jednotka na trzích NFT, jako platba za poskytování služeb nebo prodej reálného zboží atd. +**Ether (ETH)** je kryptoměna používaná k mnoha věcem v síti Ethereum. V zásadě je to jediná přijatelná forma platby za transakční poplatky a po [Sloučení](/roadmap/merge) je ether vyžadován k ověřování a navrhování bloků na hlavní síti. Ether se také používá jako primární forma kolaterálu na úvěrových trzích [DeFi](/defi), jako zúčtovací jednotka na NFT tržištích, jako platba za poskytnuté služby nebo prodej reálného zboží a tak dále. -Ethereum umožňuje vývojářům vytvářet [**decentralizované aplikace (dappky)**](/developers/docs/dapps), které sdílejí společný fond výpočetního výkonu. Tento sdílený fond je omezený, takže Ethereum potřebuje mechanismus, který určí, kdo ho může používat. Jinak by mohla dappka omylem nebo záměrně spotřebovat všechny síťové zdroje, což by znemožnilo přístup ostatním. +Ethereum umožňuje vývojářům vytvářet [**decentralizované aplikace (dapps)**](/developers/docs/dapps), které všechny sdílejí společný výpočetní výkon. Tento sdílený fond je omezený, takže Ethereum potřebuje mechanismus, který určí, kdo ho může používat. Jinak by mohla dappka omylem nebo záměrně spotřebovat všechny síťové zdroje, což by znemožnilo přístup ostatním. -Kryptoměna ether podporuje mechanismus stanovení cen pro výpočetní výkon Etherea. Když uživatelé chtějí provést transakci, musí zaplatit Ethereum, aby byla jejich transakce na blockchainu uznána. Tyto náklady jsou známé jako [poplatky za palivo](/developers/docs/gas/) a výše poplatku závisí na množství výpočetního výkonu potřebného k provedení transakce a na celosíťové poptávce po výpočetním výkonu v daném okamžiku. +Kryptoměna ether podporuje mechanismus stanovení cen pro výpočetní výkon Etherea. Když uživatelé chtějí provést transakci, musí zaplatit etherem, aby byla jejich transakce na blockchainu uznána. Tyto náklady na použití jsou známé jako [poplatky za gas](/developers/docs/gas/) a poplatek za gas závisí na množství výpočetního výkonu potřebného k provedení transakce a na celosíťové poptávce po výpočetním výkonu v daném okamžiku. Proto, i když by škodlivá dappka odeslala nekonečnou smyčku, transakci by nakonec došel ether a byla by ukončena, což by umožnilo síti vrátit se do normálu. -Je [běžné zaměňovat](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) Ethereum a ether – když se lidé zmiňují o „ceně Etherea“, popisují cenu etheru. +Je [běžné zaměňovat](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) Ethereum a ether — když lidé mluví o „ceně Etherea“, popisují cenu etheru. ## Ražba etheru {#minting-ether} @@ -38,15 +38,15 @@ Ether se razí jako odměna za každý navržený blok a při každém epocháln Kromě vytváření etheru prostřednictvím odměn za bloky může být ether také zničen procesem zvaným „pálení“. Když se ether spálí, je trvale odstraněn z oběhu. -K pálení etheru dochází při každé transakci na Ethereu. Když uživatelé platí za transakce, základní poplatek za palivo, který je stanoven sítí podle poptávky po transakcích, je zničen. Tento proces, ve spojení s proměnlivými velikostmi bloků a maximálním poplatkem za palivo, zjednodušuje odhad poplatků za transakce na Ethereu. Když je poptávka po síti vysoká, [bloky](https://etherscan.io/block/12965263) mohou spálit více etheru, než kolik se vyrazí, což efektivně kompenzuje vydávání nových etherů. +K pálení etheru dochází při každé transakci na Ethereu. Když uživatelé platí za transakce, základní poplatek za palivo, který je stanoven sítí podle poptávky po transakcích, je zničen. Tento proces, ve spojení s proměnlivými velikostmi bloků a maximálním poplatkem za palivo, zjednodušuje odhad poplatků za transakce na Ethereu. Když je poptávka v síti vysoká, mohou [bloky](https://eth.blockscout.com/block/22580057) spálit více etheru, než kolik vyrazí, což efektivně kompenzuje vydávání etheru. Pálení základního poplatku omezuje schopnost producenta bloku manipulovat s transakcemi. Např. kdyby producenti bloků dostávali základní poplatek, mohli by zahrnout své vlastní transakce zdarma a zvýšit základní poplatek pro všechny ostatní. Alternativně by mohli vrátit základní poplatek některým uživatelům mimo blockchain, což by vedlo k méně transparentnímu a složitějšímu trhu s transakčními poplatky. -## Denominace etheru {#denominations} +## Jednotky etheru {#denominations} Protože hodnota mnoha transakcí na Ethereu je malá, ether má několik denominací, které mohou být použity jako menší účetní jednotky. Z těchto denominací jsou obzvláště důležité wei a gwei. -Wei je nejmenší možnou jednotkou etheru, a proto se mnoho technických implementací, např. [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf), zakládá na výpočtech ve wei. +Wei je nejmenší možná částka etheru a v důsledku toho budou mnohé technické implementace, jako například [Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf), zakládat všechny výpočty na wei. Gwei, zkratka pro giga-wei, se často používá k popisu nákladů na palivo na Ethereu. @@ -55,24 +55,24 @@ Gwei, zkratka pro giga-wei, se často používá k popisu nákladů na palivo na | Wei | 10-18 | Technické implementace | | Gwei | 10-9 | Srozumitelné poplatky za palivo | -## Převod etheru {#transferring-ether} +## Převádění etheru {#transferring-ether} -Každá transakce na Ethereu obsahuje pole `hodnota`, které určuje částku etheru k převodu, denominovanou ve wei, k odeslání z adresy odesílatele na adresu příjemce. +Každá transakce na Ethereu obsahuje pole `value`, které určuje množství etheru k převodu, denominované ve wei, k odeslání z adresy odesílatele na adresu příjemce. -Když je adresou příjemce [chytrý kontrakt](/developers/docs/smart-contracts/), tento převedený ether může být použit k úhradě paliva při vykonávání kódu chytrého kontraktu. +Pokud je adresa příjemce [chytrý kontrakt](/developers/docs/smart-contracts/), může být tento převedený ether použit k zaplacení gasu, když chytrý kontrakt spouští svůj kód. -[Další informace o transakcích](/developers/docs/transactions/) +[Více o transakcích](/developers/docs/transactions/) -## Dotazování na ether {#querying-ether} +## Zjišťování zůstatku etheru {#querying-ether} -Uživatelé mohou zjistit zůstatek etheru na jakémkoliv [účtu](/developers/docs/accounts/) tím, že se podívají na pole `zůstatku` účtu, které zobrazuje hodnotu drženou v etheru v denominaci wei. +Uživatelé mohou zjistit zůstatek etheru na jakémkoli [účtu](/developers/docs/accounts/) nahlédnutím do pole `balance` daného účtu, které ukazuje držený ether v nominální hodnotě wei. -[Etherscan](https://etherscan.io) je populárním nástrojem ke zjištění zůstatků adres prostřednictvím webové aplikace. [Tato stránka na Etherscanu](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) např. ukazuje zůstatek etherů na účtu Ethereum Foundation. Zůstatky účtů lze také zjistit pomocí peněženek nebo přímo pomocí vyslání požadavku na uzly. +[Etherscan](https://etherscan.io) a [Blockscout](https://eth.blockscout.com) jsou populární nástroje pro kontrolu zůstatků na adresách prostřednictvím webových aplikací. Například [tato stránka Blockscout](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe) ukazuje zůstatek Nadace Ethereum. Zůstatky účtů lze také zjistit pomocí peněženek nebo přímo pomocí vyslání požadavku na uzly. -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Definování etheru a Etherea](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ -- [Ethereum Whitepaper](/whitepaper/): Původní návrh Etherea. Tento dokument obsahuje popis etheru a motivaci za jeho vytvořením. -- [Kalkulačka gwei](https://www.alchemy.com/gwei-calculator): Použijte tuto kalkulačku gwei pro snadnou konverzi mezi wei, gwei a ether. Stačí zadat jakoukoliv částku ve wei, gwei nebo ETH a automaticky vypočítat konverzi. +- [Definice etheru a Etherea](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Bílá kniha Etherea](/whitepaper/): Původní návrh Etherea. Tento dokument obsahuje popis etheru a motivaci za jeho vytvořením. +- [Kalkulačka gwei](https://www.alchemy.com/gwei-calculator): Použijte tuto kalkulačku gwei pro snadný převod mezi wei, gwei a etherem. Stačí zadat jakoukoliv částku ve wei, gwei nebo ETH a automaticky vypočítat konverzi. _Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ diff --git a/public/content/translations/cs/developers/docs/intro-to-ethereum/index.md b/public/content/translations/cs/developers/docs/intro-to-ethereum/index.md index 8e8d75df56c..a2888cb7189 100644 --- a/public/content/translations/cs/developers/docs/intro-to-ethereum/index.md +++ b/public/content/translations/cs/developers/docs/intro-to-ethereum/index.md @@ -1,6 +1,6 @@ --- -title: Úvod k platformě Ethereum -description: Úvod do základních konceptů Etherea pro vývojáře dappek. +title: "Technický úvod do Etherea" +description: "Úvod do základních konceptů Etherea pro vývojáře dappek." lang: cs --- @@ -16,13 +16,13 @@ Každý počítač v síti musí souhlasit s každým novým blokem a řetězcem Ethereum používá [mechanismus konsenzu založený na důkazu podílem](/developers/docs/consensus-mechanisms/pos/). Každý, kdo chce přidat nové bloky do řetězce, musí uzamknout ETH – nativní měnu v Ethereu – jako záruku a spustit validační software. Tito „validátoři“ mohou být pak náhodně vybráni k navržení bloků, které ostatní validátoři zkontrolují a přidají na blockchain. Existuje systém odměn a trestů, který silně motivuje účastníky, aby byli poctiví a co nejvíce online. -Pokud se chcete podívat, jak jsou blockchainová data hashována a následně přidávána k historii odkazů bloků, podívejte se na [tuto ukázku](https://andersbrownworth.com/blockchain/blockchain) od Anderse Brownwortha na videu níže. +Pokud se chcete podívat, jak se data v blockchainu hašují a následně připojují k historii odkazů na bloky, určitě si prohlédněte [tuto ukázku](https://andersbrownworth.com/blockchain/blockchain) od Anderse Brownwortha a podívejte se na doprovodné video níže. Podívejte se, jak Anders vysvětluje hashe na blockchainech: -## Co je to Ethereum? {#what-is-ethereum} +## Co je to Ethereum? Co je Ethereum? {#what-is-ethereum} Ethereum je blockchain s integrovaným počítačem. Je základem pro budování aplikací a organizací decentralizovaným, cenzuře odolným způsobem bez nutnosti dovolovat se třetí strany. @@ -32,7 +32,7 @@ Požadavky na výpočet se nazývají transakční požadavky. Záznam všech tr Kryptografické mechanismy zajišťují, že jakmile jsou transakce ověřeny jako platné a přidány na blockchain, nemohou být později zmanipulovány. Tyto mechanismy také zajišťují, že všechny transakce jsou podepsány a provedeny s odpovídajícími „oprávněními“ (nikdo by neměl být schopen poslat digitální aktiva z účtu Alice, kromě Alice samotné). -## Co je ether? {#what-is-ether} +## Co je to ether? {#what-is-ether} **Ether (ETH)** je nativní kryptoměna Etherea. Účelem ETH je umožnit fungování trhu výpočetních zdrojů. Takový trh poskytuje účastníkům ekonomickou pobídku k ověřování a provádění požadavků na transakce a poskytování výpočetních zdrojů síti. @@ -42,9 +42,9 @@ Množství zaplaceného ETH odpovídá zdrojům potřebným k provedení výpoč ETH se také používá k zajištění kryptografické bezpečnosti sítě třemi hlavními způsoby: 1) Slouží jako prostředek k odměňování validátorů, kteří navrhují bloky nebo upozorňují na nepoctivé chování jiných validátorů. 2) Validátoři ho uzamykají jako záruku proti nepoctivému chování – pokud se validátoři pokusí o nekalou činnost, jejich ETH může být zničeno. 3) Používá se k vážení „hlasů“ pro nově navrhované bloky, což se promítá do volby větve v mechanismu konsenzu. -## Co to jsou chytré kontrakty? {#what-are-smart-contracts} +## Co to jsou chytré kontrakty? Co jsou chytré kontrakty? {#what-are-smart-contracts} -V praxi účastníci nepíší nový kód pokaždé, když chtějí požádat o výpočet na EVM. Místo toho vývojáři aplikací nahrají programy (znovu použitelné úryvky kódu) do stavu EVM a uživatelé posílají požadavky na provedení těchto úryvků kódu s různými parametry. Tyto programy, které jsou nahrány do sítě a touto sítí také vykonávány, nazýváme chytré kontrakty. +V praxi účastníci nepíší nový kód pokaždé, když chtějí požádat o výpočet na EVM. Místo toho vývojáři aplikací nahrají programy (znovu použitelné úryvky kódu) do stavu EVM a uživatelé posílají požadavky na provedení těchto úryvků kódu s různými parametry. Programy nahrané do sítě, které síť zároveň vykonává, nazýváme "chytré kontrakty". Na základní úrovni si můžete chytrý kontrakt představit jako druh automatu: Skript, který při volání s určitými parametry, pokud jsou splněny určité podmínky, provádí nějaké akce nebo výpočet. Např. jednoduchý vydávající chytrý kontrakt by mohl vytvořit a přiřadit vlastnictví digitálního aktiva, pokud volající pošle ETH konkrétnímu příjemci. @@ -62,15 +62,15 @@ Sekvence všech bloků, které byly historicky přidány na síť Ethereum. Toto **Ether (ETH)** je nativní kryptoměna Etherea. Uživatelé platí ETH jiným uživatelům, aby byly splněny jejich požadavky na vykonání kódu. -[Více o ETH](/developers/docs/intro-to-ether/) +[Více o ETH](/developers/docs/intro-to-ether/) ### EVM {#evm} Virtuální stroj Etherea (EVM) je globální virtuální počítač, jehož stav uchovává a uznává každý účastník sítě Ethereum. Každý účastník může požádat o vykonání libovolného kódu na EVM. To mění stav EVM. -[Další informace o EVM](/developers/docs/evm/) +[Více o EVM](/developers/docs/evm/) -### Síťové uzly {#nodes} +### Uzly {#nodes} Reálné stroje, které ukládají stav EVM. Uzly mezi sebou komunikují, aby sdílely informace o stavu EVM a jeho změnách. Každý uživatel může také požádat o vykonání kódu tím, že z uzlu vyšle požadavek na vykonání kódu. Samotná síť Ethereum je souhrnem všech uzlů Etherea a jejich komunikací. @@ -80,7 +80,7 @@ Reálné stroje, které ukládají stav EVM. Uzly mezi sebou komunikují, aby sd Místo, kde je uloženo ETH. Uživatelé mohou inicializovat účty, vkládat ETH na účty a převádět ETH ze svých účtů na účty jiných uživatelů. Účty a zůstatky na účtech jsou uloženy ve velké tabulce v EVM. Jsou součástí celkového stavu EVM. -[Další informace o účtech](/developers/docs/accounts/) +[Více o účtech](/developers/docs/accounts/) ### Transakce {#transactions} @@ -90,27 +90,35 @@ Místo, kde je uloženo ETH. Uživatelé mohou inicializovat účty, vkládat ET - Nahraj nějaký chytrý kontraktový kód do stavu EVM. - Vykonej kód chytrého kontraktu na adrese X v EVM s argumenty Y. -[Další informace o transakcích](/developers/docs/transactions/) +[Více o transakcích](/developers/docs/transactions/) ### Bloky {#blocks} Objem transakcí je velmi vysoký, takže transakce jsou „zapisovány“ v dávkách neboli blocích. Bloky obvykle obsahují desítky až stovky transakcí. -[Další informace o blocích](/developers/docs/blocks/) +[Více o blocích](/developers/docs/blocks/) ### Chytré kontrakty {#smart-contracts} -Znovu použitelný úryvek kódu (program), který vývojář nahraje do stavu EVM. Každý může podáním transakčního požadavku požádat o vykonání kódu chytrého kontraktu. Protože vývojáři mohou do EVM zapisovat libovolné spustitelné aplikace (hry, tržiště, finanční nástroje atd.) tím, že publikují chytré kontrakty, často se jim říká [dappky nebo decentralizované aplikace](/developers/docs/dapps/). +Znovu použitelný úryvek kódu (program), který vývojář nahraje do stavu EVM. Každý může podáním transakčního požadavku požádat o vykonání kódu chytrého kontraktu. Protože vývojáři mohou do EVM psát libovolné spustitelné aplikace (hry, tržiště, finanční nástroje atd.) zveřejňováním chytrých kontraktů se těmto často říká také [dapps neboli decentralizované aplikace](/developers/docs/dapps/). [Více o chytrých kontraktech](/developers/docs/smart-contracts/) -## Další četba {#further-reading} +## Další čtení {#further-reading} -- [Oficiální dokumenty Ethereum](/whitepaper/) -- [Jak vlastně Ethereum funguje?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) – _Preethi Kasireddy_ (**Poznámka**: Tento zdroj je stále užitečný, ale vezměte na vědomí, že předchází [Sloučení](/roadmap/merge), a proto stále odkazuje na mechanismus důkazu prací – Ethereum je nyní zabezpečeno pomocí [důkazu podílem.](/developers/docs/consensus-mechanisms/pos)) +- [Bílá kniha Ethereum](/whitepaper/) +- [Jak vlastně Ethereum funguje?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**Poznámka:** tento zdroj je stále hodnotný, ale uvědomte si, že předchází [Sloučení](/roadmap/merge) a tudíž stále odkazuje na mechanismus důkazu prací – Ethereum je ve skutečnosti nyní zabezpečeno pomocí [důkazu podílem](/developers/docs/consensus-mechanisms/pos)) + +### Učíte se spíše vizuálně? Vizuální výuka {#visual-learner} + +Tato série videí nabízí důkladné prozkoumání základních témat: + + + +[Playlist se základy Etherea](https://youtube.com/playlist?list=PLqgutSGloqiJyyoL0zvLVFPS-GMD2wKa5&si=kZTf5I7PKGTXDsOZ) _Víte o komunitním zdroji, který vám pomohl? Upravte tuto stránku a přidejte ho!_ ## Související návody {#related-tutorials} -- [Průvodce Ethereem pro vývojáře, část 1](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Velmi přívětivý průvodce Ethereem používající Python a web3.py_ +- [Průvodce Ethereem pro vývojáře, 1. část](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Velice srozumitelné seznámení s Ethereem pro začátečníky s použitím Pythonu a web3.py_ diff --git a/public/content/translations/cs/developers/docs/mev/index.md b/public/content/translations/cs/developers/docs/mev/index.md new file mode 100644 index 00000000000..2c7cbb4e8d7 --- /dev/null +++ b/public/content/translations/cs/developers/docs/mev/index.md @@ -0,0 +1,222 @@ +--- +title: "Maximální extrahovatelná hodnota (MEV)" +description: "Úvod do maximální extrahovatelné hodnoty (MEV)" +lang: cs +--- + +Maximální extrahovatelná hodnota (MEV) označuje maximální hodnotu, kterou lze získat z produkce bloku nad rámec standardní odměny za blok a poplatků za palivo tím, že se do bloku zahrnou, vyloučí se nebo se změní pořadí transakcí. + +## Maximální vytěžitelná hodnota {#maximal-extractable-value} + +Maximální vytěžitelná hodnota byla poprvé použita v kontextu [proof-of-work](/developers/docs/consensus-mechanisms/pow/) a původně se označovala jako „miner extractable value“ (hodnota vytěžitelná těžařem). To proto, že v systému proof of work ovládají zahrnutí, vyloučení a pořadí transakcí těžaři. Po přechodu na proof-of-stake prostřednictvím [The Merge](/roadmap/merge) však za tyto role převzali odpovědnost validátoři a těžba již není součástí protokolu Ethereum. Metody extrakce hodnoty však stále existují, a proto se nyní používá termín "maximální extrahovatelná hodnota". + +## Předpoklady {#prerequisites} + +Ujistěte se, že jste obeznámeni s [transakcemi](/developers/docs/transactions/), [bloky](/developers/docs/blocks/), [proof-of-stake](/developers/docs/consensus-mechanisms/pos) a [palivem](/developers/docs/gas/). Znalost [dapps](/apps/) a [DeFi](/defi/) je také užitečná. + +## Extrakce MEV {#mev-extraction} + +MEV teoreticky plně připadne validátorům, protože jsou jedinou stranou, která může šanci na ziskovou MEV zrealizovat. V praxi však velkou část MEV extrahují nezávislí účastníci sítě, označovaní jako "hledači" (searchers). Hledači aplikují na blockchainová data složité algoritmy za účelem detekce ziskových MEV příležitostí a spouští robotické programy, které automaticky posílají tyto ziskové transakce do sítě. + +Validátoři přesto získávají část hodnoty MEV, protože hledači jsou ochotni platit vysoké poplatky za palivo (které jdou validátorům) výměnou za vyšší pravděpodobnost zahrnutí jejich ziskových transakcí do bloku. Předpokládá se, že hledači jsou ekonomicky racionální, a poplatek za palivo, který jsou ochotni zaplatit, bude činit až 100 % jejich MEV (protože pokud by byl poplatek vyšší, hledač by prodělával). + +V případě vysoce konkurenčních příležitostí k MEV, jako je [arbitráž na DEX](#mev-examples-dex-arbitrage), mohou hledači validátorům zaplatit 90 % nebo více ze svých celkových příjmů z MEV na poplatcích za palivo, protože mnoho lidí chce provést stejný ziskový arbitrážní obchod. Jediným způsobem, jak zajistit, aby jejich arbitrážní transakce proběhla, je zaslat transakci s nejvyšším palivovým poplatkem. + +### Gas golfing {#mev-extraction-gas-golfing} + +Tato dynamika způsobila, že vynikat v "gas golfu" — programování transakcí tak, aby spotřebovávaly co nejméně paliva — je konkurenční výhodou, protože to umožňuje hledačům nastavit vyšší cenu za palivo a udržet přitom své celkové palivové poplatky na stejné úrovni (protože poplatky za palivo = cena paliva \* spotřebované palivo). + +Některé známé techniky „gas golfing“ zahrnují: používání adres, které začínají dlouhým řetězcem nul (např. [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)), protože zabírají méně místa (a tedy i paliva) k uložení; a ponechání malých zůstatků tokenů [ERC-20](/developers/docs/standards/tokens/erc-20/) ve smlouvách, protože inicializace úložného slotu (v případě, že je zůstatek 0) stojí více paliva než aktualizace úložného slotu. Hledání dalších technik ke snížení spotřeby paliva je mezi hledači aktivní oblastí výzkumu. + +### Generalizovaní frontrunneři {#mev-extraction-generalized-frontrunners} + +Někteří hledači provozují generalizované frontrunnery místo programování složitých algoritmů pro detekci ziskových MEV příležitostí. Generalizovaní frontrunneři jsou robotické programy, které sledují mempool a detekují ziskové transakce. Frontrunner zkopíruje kód potenciálně ziskové transakce, nahradí adresy vlastní adresou a lokálně spustí transakci, aby se přesvědčil, že frontrunner na upravené transakci vydělá. Pokud je transakce skutečně zisková, frontrunner odešle upravenou transakci s nahrazenou adresou a nabídne vyšší cenu za palivo, "předběhne" původní transakci a získá MEV původního hledače. + +### Flashbots {#mev-extraction-flashbots} + +Flashbots je nezávislý projekt, který rozšiřuje exekuční klienty o službu, která hledačům umožňuje předkládat MEV transakce validátorům, aniž by je odhalovali veřejnému mempoolu. Tímto způsobem se zabraňuje tomu, aby transakce předběhli generalizovaní frontrunneři. + +## Příklady MEV {#mev-examples} + +MEV se na blockchainu objevuje v několika podobách. + +### Arbitráž na DEX {#mev-examples-dex-arbitrage} + +Arbitráž na [decentralizované burze](/glossary/#dex) (DEX) je nejjednodušší a nejznámější příležitostí k získání MEV. Výsledkem je, že je také nejkonkurenčnější. + +Funguje to takto: Pokud dva DEXy nabízejí token za dvě různé ceny, někdo může v jediné atomické transakci koupit token na DEXu s nižší cenou a prodat ho na DEXu s vyšší cenou. Díky mechanice blockchainu je tato arbitráž bezriziková. + +[Zde je příklad](https://eth.blockscout.com/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) ziskové arbitrážní transakce, při které hledač proměnil 1 000 ETH na 1 045 ETH tím, že využil rozdílných cen páru ETH/DAI na Uniswap vs. Sushiswap. + +### Likvidace {#mev-examples-liquidations} + +Likvidace v protokolech poskytujících půjčky představují další známou příležitost pro MEV. + +Půjčovací protokoly jako Maker a Aave vyžadují, aby uživatelé vložili nějaký kolaterál (např. ETH). Tento vložený kolaterál se pak půjčuje dalším uživatelům. + +Uživatelé si pak mohou půjčovat aktiva a tokeny od ostatních v závislosti na tom, co potřebují (např. si můžete půjčit MKR, pokud chcete hlasovat v návrhu správy MakerDAO), a to až do určitého procenta svého vloženého kolaterálu. Například pokud je maximální výše půjčky 30 %, může si uživatel, který vloží do protokolu 100 DAI, půjčit až 30 DAI v hodnotě jiného aktiva. Přesné procento půjčovací síly určuje protokol. + +Jak se hodnota kolaterálu dlužníka mění, mění se i jeho půjčovací síla. Pokud v důsledku výkyvů na trhu hodnota vypůjčených aktiv přesáhne řekněme 30 % hodnoty jejich kolaterálu (přesné procento opět určuje protokol), protokol obvykle komukoli umožní kolaterál zlikvidovat a okamžitě vyplatit věřitele (podobně fungují i [margin calls](https://www.investopedia.com/terms/m/margincall.asp) v tradičním finančnictví). Pokud je kolaterál zlikvidován, musí dlužník obvykle zaplatit vysoký poplatek za likvidaci, z čehož jde část likvidátorovi – a právě zde se objevuje příležitost pro MEV. + +Hledači soutěží v co nejrychlejším zpracování blockchainových dat, aby zjistili, které dlužníky je možné zlikvidovat, a aby jako první podali likvidační transakci a získali tak poplatek za likvidaci. + +### Sendvičové obchodování {#mev-examples-sandwich-trading} + +Jedná se o další běžnou metodu extrakce MEV. + +Chcete-li hledač provést sendvičový obchod, bude v mempoolu hledat velké DEX obchody. Například, pokud chce někdo koupit 10 000 UNI za DAI na Uniswapu. Takový obchod bude mít významný vliv na pár UNI/DAI, což může výrazně zvýšit cenu UNI vůči DAI. + +Hledač může vypočítat přibližný cenový dopad tohoto velkého obchodu na pár UNI/DAI a provést optimální nákupní příkaz okamžitě _před_ velkým obchodem, levně tak nakoupit UNI, a poté provést prodejní příkaz okamžitě _po_ velkém obchodu a prodat ho za vyšší cenu způsobenou velkým příkazem. + +Sendvičové obchodování je však rizikovější, protože není atomické (na rozdíl od výše popsané arbitráže na DEX) a je náchylné k [útoku salmonelou](https://github.com/Defi-Cartel/salmonella). + +### NFT MEV {#mev-examples-nfts} + +MEV v prostoru NFT je vznikajícím fenoménem a nemusí být nutně zisková. + +Jelikož se však NFT transakce odehrávají na stejném blockchainu jako všechny ostatní transakce na Ethereu, mohou hledači používat podobné techniky jako ty, které se používají u tradičních příležitostí MEV, i na trhu NFT. + +Například pokud je nějaký populární NFT drop a hledač chce určité NFT nebo sadu NFT, může naprogramovat transakci tak, aby byl první v řadě na nákup NFT, nebo může koupit celou sadu NFT v jedné transakci. Nebo pokud je NFT [omylem zalistováno za nízkou cenu](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), může hledač předběhnout ostatní kupující a levně ho získat. + +Jeden významný příklad NFT MEV nastal, když hledač utratil 7 milionů dolarů za [nákup](https://eth.blockscout.com/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5?tab=txs) všech Cryptopunků za nejnižší možnou cenu. Jeden blockchainový výzkumník [vysvětlil na Twitteru](https://twitter.com/IvanBogatyy/status/1422232184493121538), jak kupující spolupracoval s poskytovatelem MEV, aby svůj nákup utajil. + +### Dlouhý chvost {#mev-examples-long-tail} + +Arbitráž na DEXech, likvidace a sendvičové obchodování jsou všechny velmi známé příležitosti pro MEV a pro nové hledače jsou pravděpodobně neziskové. Existuje však dlouhý chvost méně známých příležitostí pro MEV (NFT MEV je pravděpodobně jednou z takových příležitostí). + +Začínající hledači, mohou mít větší úspěch, pokud budou hledat MEV v tomto dlouhém chvostu. [Pracovní nástěnka MEV](https://github.com/flashbots/mev-job-board) od Flashbotů uvádí některé nově vznikající příležitosti. + +## Účinky MEV {#effects-of-mev} + +MEV není vždy špatná - pro Ethereum má jak pozitivní, tak negativní důsledky. + +### Pozitiva {#effects-of-mev-the-good} + +Mnohé DeFi projekty se za účelem zajištění užitečnosti a stability svých protokolů spoléhá na ekonomicky racionální aktéry. Arbitráž na DEXech například zajišťuje, že uživatelé mohou své tokeny směnit za nejlepší a nejpřesnější ceny, a protokoly poskytující půjčky se spoléhají na rychlé likvidace, když dlužníci klesnou pod kolateralizační poměry, aby zajistili, že věřitelé budou vyplaceni. + +Bez racionálních hledačů, kteří vyhledávají a opravují ekonomické neefektivity a využívají ekonomické pobídky protokolů, by DeFi protokoly a dappky obecně nemusely být tak robustní, jak dnes jsou. + +### Negativa {#effects-of-mev-the-bad} + +Některé formy MEV, jako je sendvičové obchodování, vedou na aplikační vrstvě k jednoznačně horší uživatelské zkušenosti. Uživatelé, kteří jsou „sendvičováni“, čelí zvýšenému riziku pohybu ceny a horší exekuci svých obchodů. + +Na síťové vrstvě vedou generalizovaní frontrunneři a aukce palivových cen, kterých se často účastní (když dva nebo více frontrunnerů soutěží o zařazení své transakce do dalšího bloku postupným zvyšováním ceny za palivo u svých transakcí), k přetížení sítě a vysokým poplatkům pro všechny ostatní, kteří se snaží provádět běžné transakce. + +Kromě toho, co se děje _uvnitř_ bloků, může mít MEV škodlivé účinky i _mezi_ bloky. Pokud MEV dostupná v bloku výrazně převyšuje standardní odměnu za blok, mohou být validátoři motivováni k reorganizaci bloků a uzmutí MEV pro sebe, což způsobí reorganizaci blockchainu a destabilizaci konsensu. + +Tato možnost reorganizace blockchainu byla [již dříve prozkoumána na blockchainu Bitcoinu](https://dl.acm.org/doi/10.1145/2976749.2978408). Jak se odměna za blok na Bitcoinu snižuje a transakční poplatky tvoří stále větší část odměny, vznikají situace, kdy se pro těžaře stává ekonomicky racionálním vzdát se odměny za další blok a místo toho znovu vytěžit minulé bloky s vyššími poplatky. S růstem MEV by se stejná situace mohla vyskytnout i na Ethereu, což by ohrozilo integritu blockchainu. + +## Stav MEV {#state-of-mev} + +Extrakce MEV prudce vzrostla na začátku roku 2021, což vedlo k extrémně vysokým cenám za palivo v prvních měsících tohoto roku. Vznik MEV-relay od Flashbotů snížil účinnost generalizovaných frontrunnerů a aukce cen za palivo přesunul mimo řetězec, čímž snížil ceny za palivo pro běžné uživatele. + +I když spousta hledačů stále vydělává na MEV slušné peníze, jakmile se tyto příležitosti stanou známějšími a stále více hledačů bude soutěžit o stejnou příležitost, validátoři začnou získávat stále větší podíl z celkových příjmů z MEV (protože stejné palivové aukce, jak byly původně popsány výše, se stále vyskytují i ve Flashbotech, i když soukromě, a validátoři tak získávají příjmy z transakčních poplatků). MEV není omezeno pouze na Ethereum, a jakmile budou příležitosti na Ethereu více konkurenční, hledači se přesunou na alternativní blockchainy, jako je Binance Smart Chain, kde existují podobné MEV příležitosti jako na Ethereu, ale s menší konkurencí. + +Na druhé straně přechod z proof of work na proof of stake a probíhající snahy o škálování Etherea pomocí rollupů mění MEV způsoby, které jsou zatím nejasné. Zatím není dobře známo, jak to, že jsou garantovaní navrhovatelé bloků známi s mírným předstihem, mění dynamiku extrakce MEV v porovnání s pravděpodobnostním modelem v proof-of-work, ani jak to bude narušeno, až bude implementována [volba jednoho tajného vůdce](https://ethresear.ch/t/secret-non-single-leader-election/11789) a [technologie distribuovaných validátorů](/staking/dvt/). Podobně není jasné, jaké MEV příležitosti budou existovat, když většina uživatelské aktivity přejde mimo Ethereum a na jeho rollupy druhé vrstvy a shardy. + +## MEV v Ethereu s Proof-of-Stake (PoS) {#mev-in-ethereum-proof-of-stake} + +Jak jsme vysvětlili výše, MEV má negativní dopady na celkovou uživatelskou zkušenost a bezpečnost na úrovni konsensu. Přechod Etherea na konsensus proof of stake (tzv. "Sloučení") však potenciálně přináší nová rizika spojená s MEV: + +### Centralizace validátorů {#validator-centralization} + +Na Ethereu po sloučení validátoři (kteří složili bezpečnostní zálohu ve výši 32 ETH) dosahují konsensu o platnosti bloků přidávaných do Beacon Chainu. Jelikož 32 ETH může být pro mnohé mimo dosah, může být schůdnější variantou [připojení se ke staking poolu](/staking/pools/). Nicméně ideální je zdravé rozložení [sólových stakerů](/staking/solo/), protože to zmírňuje centralizaci validátorů a zlepšuje bezpečnost Etherea. + +Extrakce MEV se však předpokládá jako faktor, který může urychlit centralizaci validátorů. Je to částečně proto, že od [The Merge](/roadmap/merge/) validátoři [za navrhování bloků vydělávají méně](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply) než dříve těžaři a extrakce MEV výrazně [ovlivnila výdělky validátorů](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb). + +Větší stakingové pooly budou mít pravděpodobně více prostředků k investování do potřebných optimalizací pro zachycení příležitostí k MEV. Čím více MEV tyto pooly vytěží, tím více prostředků mají na zlepšení svých schopností extrakce MEV (a na zvýšení celkových příjmů), což v podstatě vytváří [úspory z rozsahu](https://www.investopedia.com/terms/e/economiesofscale.asp#). + +S menším objemem prostředků, které mají k dispozici, nebudou nezávislí stakeři schopni využívat příležitostí k MEV v takovém rozsahu jako pooly. To může zvýšit tlak na nezávislé validátory, aby se připojili k mocným stakingovým poolům a zvýšili své příjmy, což snižuje míru decentralizace Etherea. + +### Mempooly s oprávněním {#permissioned-mempools} + +V reakci na sendvičové útoky a frontrunning mohou obchodníci za účelem zajištění soukromí transakcí začít uzavírat offchain dohody s validátory. Místo toho, aby posílali potenciální MEV transakci do veřejného mempoolu, pošlou ji přímo validátorovi, který ji zahrne do bloku a o zisk se s obchodníkem rozdělí. + +„Temné pooly“ jsou větší verzí tohoto uspořádání a fungují jako mempooly, pro vstup do nich dostanou povolení uživatelé, kteří jsou ochotni platit určité poplatky. Tento trend by mohl oslabit charakter Etherea založený na přístupu bez nutnosti povolení a bez nutnosti důvěry a potenciálně transformovat blockchain do mechanismu „plať, pak hraj“, který zvýhodňuje uchazeče s nejvyšším příhozem. + +Mempooly s nutností povolení by také zrychlily centralizační rizika popsaná v předchozí sekci. Velké pooly provozující více validátorů budou pravděpodobně mít prospěch z nabídky soukromí během transakcí obchodníkům a dalším uživatelům, čímž zvýší své příjmy z MEV. + +Řešení těchto problémů spojených s MEV na Ethereu po sloučení je klíčovou oblastí výzkumu. K dnešnímu dni jsou dvě navrhovaná řešení ke snížení negativního dopadu MEV na decentralizaci a bezpečnost Etherea po The Merge [**oddělení navrhovatele a stavitele bloků (PBS)**](/roadmap/pbs/) a [**Builder API**](https://github.com/ethereum/builder-specs). + +### Oddělení navrhovatele a stavitele bloků {#proposer-builder-separation} + +V rámci proof of work i proof of stake navrhuje síťový uzel, který vytvoří blok, jeho přidání do řetězce ostatním uzlům, které se účastní konsenzu. Nový blok se stane součástí kanonického řetězce poté, co na něm staví další těžař (v PoW) nebo obdrží atestace od většiny validátorů (v PoS). + +Kombinace rolí tvůrce bloku a navrhovatele bloku je to, co přináší většinu problémů souvisejících s MEV, jak bylo popsáno výše. Například konsensuální uzly jsou motivovány spouštět reorganizace řetězce při [útocích typu time-bandit](https://www.mev.wiki/attack-examples/time-bandit-attack), aby maximalizovaly výdělky z MEV. + +[Oddělení navrhovatele a stavitele bloků](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) (PBS) je navrženo tak, aby zmírnilo dopad MEV, zejména na konsensuální vrstvě. Hlavním rysem PBS je oddělení rolí producenta bloku a navrhovatele bloku. Validátoři jsou stále zodpovědní za navrhování a hlasování o blocích, ale nová třída specializovaných entit, nazývaných **stavitelé bloků**, má za úkol seřazovat transakce a stavět bloky. + +V rámci PBS stavitel bloku vytvoří balík transakcí a podá nabídku na jeho zahrnutí do bloku Beacon Chain (jako „execution payload“). Validátor vybraný k navržení dalšího bloku poté porovná různé nabídky a vybere balíček s nejvyšším poplatkem. PBS v podstatě vytváří aukční trh, kde stavitelé jednají s validátory, kteří prodávají prostor v bloku. + +Současné návrhy PBS používají [schéma commit-reveal](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/), ve kterém stavitelé bloků publikují pouze kryptografický závazek k obsahu bloku (hlavička bloku) spolu se svými nabídkami. Po přijetí vítězné nabídky vytvoří navrhovatel podepsaný návrh bloku, který obsahuje hlavičku bloku. Očekává se, že stavitel bloku zveřejní celé tělo bloku poté, co uvidí podepsaný návrh bloku, a před jeho finalizací musí také obdržet dostatek [atestací](/glossary/#attestation) od validátorů. + +#### Jak oddělení navrhovatele a stavitele bloků zmírňuje dopad MEV? {#how-does-pbs-curb-mev-impact} + +Oddělení navrhovatele a stavitele v rámci protokolu snižuje vliv MEV na konsenzus tím, že validátorům odebírá možnost extrakce MEV. Místo toho budou příležitosti k MEV zachycovat stavitelé bloků, kteří provozují specializovaný hardware. + +To však neznamená, že by validátoři byli zcela vyloučeni z příjmů souvisejících s MEV, protože stavitelé bloků musí nabízet vysoké částky, aby validátoři jejich bloky byly přijali. Nicméně díky tomu, že validátoři se už nebudou přímo zaměřovat na optimalizaci příjmů z MEV, se snižuje hrozba rychlých útoků. + +Oddělení navrhovatele a stavitele také snižuje rizika centralizace spojená s MEV. Například použití schématu přispěj-odhal odstraňuje potřebu důvěry stavitelů, že validátoři neukradnou příležitost k MEV nebo ji nezveřejní ostatním stavitelům. To snižuje bariéru pro sólové stakery, aby mohli těžit z MEV, jinak by stavitelé bloků měli tendenci upřednostňovat velké pooly s offchain reputací a uzavírat s nimi offchain dohody. + +Podobně validátoři nemusí důvěřovat stavitelům bloků a mohou se spolehnout, že nezatajili tělo bloku nebo nezveřejnili neplatné bloky, protože platba je bezpodmínečná. Poplatek pro validátora je zpracován i v případě, že navržený blok není dostupný nebo je jinými validátory prohlášen za neplatný. V tomto případě je blok jednoduše vyřazen, což způsobí, že stavitel bloku přijde o všechny transakční poplatky a příjmy z MEV. + +### Builder API {#builder-api} + +Zatímco oddělení navrhovatelů a stavitelů bloků slibuje snížení dopadů extrakce MEV, jeho implementace vyžaduje změny v konsensuálním protokolu. Konkrétně by bylo třeba aktualizovat pravidlo pro [výběr větve](/developers/docs/consensus-mechanisms/pos/#fork-choice) na Beacon Chainu. [Builder API](https://github.com/ethereum/builder-specs) je dočasné řešení, jehož cílem je poskytnout funkční implementaci oddělení navrhovatele a stavitele bloků, i když s vyššími předpoklady důvěry. + +Builder API je upravená verze [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md), kterou používají klienti konsensuální vrstvy k vyžádání datových částí od klientů exekuční vrstvy. Jak je uvedeno ve [specifikaci poctivého validátora](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md), validátoři vybraní k navrhování bloků požadují balíček transakcí od připojeného exekučního klienta, který zahrnou do navrhovaného bloku Beacon Chainu. + +API stavitele také funguje jako prostředník mezi validátory a klienty exekuční vrstvy; liší se však tím, že validátorům na Beacon Chainu umožňuje získávat bloky od externích subjektů (namísto vytváření bloku lokálně pomocí klienta exekuční vrstvy). + +Níže uvádíme přehled, jak API stavitele funguje: + +1. API stavitele připojuje validátora k síti stavitelů bloků, kteří provozují klienty exekuční vrstvy. Stejně jako u PBS, stavitelé jsou specializované subjekty, které investují do náročného budování bloků a k maximalizaci příjmů z MEV a spropitného za prioritní zpracování používají různé strategie. + +2. Validátor (provozující klienta konsenzuální vrstvy) žádá exekuční payload spolu s nabídkami od sítě stavitelů. Nabídky od stavitelů obsahují hlavičku exekučního payloadu – kryptografický závazek k obsahu payloadu – a poplatek, který má být uhrazen validátorovi. + +3. Validátor projde příchozí nabídky a vybere exekuční payload s nejvyšším poplatkem. Pomocí API stavitele vytvoří validátor "zaslepený" návrh Beacon bloku, který obsahuje pouze jeho podpis a hlavičku exekučního payloadu, a pošle jej staviteli. + +4. Od stavitele provozujícího API stavitele se očekává, že po zhlédnutí zaslepeného návrhu bloku odpoví plným exekučním payloadem. To validátorovi umožňuje vytvořit "podepsaný" Beacon blok, který poté rozšíří po celé síti. + +5. Od validátora používající API stavitele se stále očekává, že vytvoří blok lokálně, pokud stavitel bloků neodpoví včas, aby nepřišel o odměny za navrhování bloků. Validátor však nemůže vytvořit další blok s použitím nyní odhalených transakcí nebo jiné sady, protože by se jednalo o _ekvivokaci_ (podepsání dvou bloků ve stejném slotu), což je přestupek, za který hrozí slashing. + +Příkladem implementace Builder API je [MEV Boost](https://github.com/flashbots/mev-boost), vylepšení [aukčního mechanismu Flashbots](https://docs.flashbots.net/Flashbots-auction/overview) navržené tak, aby omezilo negativní externality MEV na Ethereu. Aukce Flashbots umožňuje validátorům v proof-of-stake zadat práci na vytváření ziskových bloků specializovaným stranám, nazývaným **hledači**. +![Diagram detailně znázorňující tok MEV](./mev.png) + +Hledači vyhledávají lukrativní příležitosti k MEV a posílají balíčky transakcí navrhovatelům bloků spolu s [nabídkou v zalepené obálce](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) za zahrnutí do bloku. Validátor provozující mev-geth, větvenou verzi go-ethereum (Geth) klienta, musí pouze vybrat balíček s nejvyšší nabídkou a zahrnout jej jako součást nového bloku. Aby byli navrhovatelé bloků (validátoři) chráněni před spamem a neplatnými transakcemi, procházejí balíčky transakcí před doručením navrhovateli validací přes **přeposílače**. + +MEV Boost zachovává stejné fungování původní Flashbots aukce, i když s novými funkcemi navrženými pro přechod Etherea na proof of stake. Hledači stále nacházejí ziskové MEV transakce pro zahrnutí do bloků, ale za agregaci transakcí a balíčků do bloků je zodpovědná nová třída specializovaných stran nazývaných **stavitelé**. Stavitel přijímá nabídky se zapečetěnou cenou od hledačů a provádí optimalizace pro výběr nejziskovějšího pořadí. + +Štafeta je stále zodpovědná za validaci balíčků transakcí před jejich předáním navrhovateli. MEV Boost však zavádí **úschovy (escrows)** odpovědné za zajištění [dostupnosti dat](/developers/docs/data-availability/) ukládáním těl bloků zaslaných staviteli a hlaviček bloků zaslaných validátory. Zde se validátor připojený ke štafetě dotazuje na dostupné exekuční payloady a používá algoritmus řazení MEV Boost k výběru payloadové hlavičky s nejvyšší nabídkou a největším MEV spropitným. + +#### Jak API stavitele zmírňuje dopady MEV? {#how-does-builder-api-curb-mev-impact} + +Hlavním přínosem API stavitele je jeho potenciál demokratizovat přístup k MEV příležitostem. Použití přispěj-odhal schématu eliminuje potřebu důvěry a snižuje vstupní bariéry pro validátory, kteří se chtějí podílet na zisku z MEV. To by mělo snížit tlak na samostatné stakery, aby se zapojili do velkých staking poolů za účelem zvýšení zisků z MEV. + +Širší implementace API stavitele podpoří větší konkurenci mezi staviteli bloků, což zvýší odolnost vůči cenzuře. Jak validátoři přezkoumávají nabídky od různých stavitelů, stavitel, který má v úmyslu cenzurovat jednu nebo více uživatelských transakcí, musí nabídnout vyšší cenu než všichni ostatní necenzurující stavitelé, jinak neuspěje. To dramaticky zvyšuje náklady na cenzuru uživatelů a odrazuje od této praxe. + +Některé projekty, jako je MEV Boost, používají API stavitele jako součást celkové struktury navržené k zajištění soukromí transakcí určitým stranám, jako jsou obchodníci snažící se vyhnout frontrunningu nebo sendvičovým +útokům. Toho lze docílit zřízením soukromého komunikačního kanálu mezi uživateli a staviteli bloků. Na rozdíl od dříve popsaných mempoolů s nutností povolení je tento přístup prospěšný z následujících důvodů: + +1. Přítomnost většího počtu stavitelů na trhu dělá cenzuru nepraktickou, což je výhodné pro uživatele. Naopak existence centralizovaných a na důvěře založených temných poolů by koncentrovala moc v rukou několika stavitelů bloků a zvýšila by možnost cenzury. + +2. Software API stavitele je open-source, což umožňuje komukoli nabízet služby stavitelů bloků. To znamená, že uživatelé nejsou nuceni používat žádného konkrétního stavitele a zlepšuje to neutralitu a přístup k Ethereu bez nutnosti povolení. Navíc obchodníci usilující o MEV nebudou nevědomky přispívat k centralizaci používáním soukromých transakčních kanálů. + +## Související zdroje {#related-resources} + +- [Dokumentace Flashbots](https://docs.flashbots.net/) +- [Flashbots GitHub](https://github.com/flashbots/pm) +- [mevboost.org](https://www.mevboost.org/) – _Sledovač s real-time statistikami pro MEV-Boost relé a stavitele bloků_ + +## Další čtení {#further-reading} + +- [Co je to hodnota vytěžitelná těžařem (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [MEV a já](https://www.paradigm.xyz/2021/02/mev-and-me) +- [Ethereum je temný les](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [Únik z temného lesa](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: Frontrunning krize MEV](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [Vlákna o MEV od @bertcmiller](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: Architektura Flashbots připravená na The Merge](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [Co je MEV Boost](https://www.alchemy.com/overviews/mev-boost) +- [Proč používat mev-boost?](https://writings.flashbots.net/writings/why-run-mevboost/) +- [Stopařův průvodce po Ethereu](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/cs/developers/docs/networking-layer/index.md b/public/content/translations/cs/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..879a209fd87 --- /dev/null +++ b/public/content/translations/cs/developers/docs/networking-layer/index.md @@ -0,0 +1,155 @@ +--- +title: "Síťová vrstva" +description: "Úvod do síťové vrstvy Etherea." +lang: cs +sidebarDepth: 2 +--- + +Ethereum je peer-to-peer síť s tisíci uzly, které musí být schopny spolu komunikovat pomocí standardizovaných protokolů. "Síťová vrstva“ je vrstva protokolů, která umožňuje těmto uzlům se navzájem najít a vyměňovat si informace. To zahrnuje jak „gossiping“ informací (komunikaci jeden-k-mnohým) po síti, tak výměnu požadavků a odpovědí mezi konkrétními uzly (komunikace jeden na jednoho). Každý uzel musí dodržovat specifická síťová pravidla, aby zajistil, že odesílá a přijímá správné informace. + +Klientský software má dvě části (exekuční klienty a konsensuální klienty), z nichž každá má vlastní specifickou síťovou vrstvu. Kromě komunikace s ostatními uzly Etherea musí exekuční a konsensuální klienti komunikovat mezi sebou. Tato stránka poskytuje úvodní vysvětlení protokolů, které umožňují tuto komunikaci. + +Exekuční klienti šíří transakce po peer-to-peer síti exekuční vrstvy. To vyžaduje šifrovanou komunikaci mezi ověřenými peery. Když je validátor vybrán k návrhu bloku, transakce z místního transakčního poolu uzlu jsou předány konsensuálním klientům prostřednictvím lokálního RPC připojení, které je následně zabalí do Beacon bloků. Konsensuální klienti pak šíří Beacon bloky po své p2p síti. To vyžaduje dvě samostatné p2p sítě: Jednu pro propojení exekučních klientů pro gossiping transakcí a druhou pro propojení konsensuálních klientů pro gossiping bloků. + +## Předpoklady {#prerequisites} + +Některé znalosti o [uzlech a klientech](/developers/docs/nodes-and-clients/) sítě Ethereum budou užitečné pro pochopení této stránky. + +## Exekuční vrstva {#execution-layer} + +Síťové protokoly exekuční vrstvy jsou rozděleny do dvou skupin: + +- vrstva pro objevování: postavená na protokolu UDP - umožňuje novému síťovému uzlu najít kolegy, ke kterým se může připojit + +- vrstva DevP2P: běží na protokolu TCP a umožňuje uzlům vyměňovat si informace + +Obě vrstvy fungují paralelně. Vrstva pro objevování přivádí do sítě nové účastníky, zatímco vrstva DevP2P umožňuje jejich interakce. + +### Objevování {#discovery} + +Objevování je proces hledání dalších uzlů v síti. Tento proces je zahájen pomocí malé sady bootnodů (uzlů, jejichž adresy jsou [pevně zakódovány](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) v klientovi, aby je bylo možné okamžitě najít a připojit klienta k peerům). Tyto bootnody existují pouze za účelem představení nového uzlu sadě kolegů - to je jejich jediný účel, neúčastní se normálních úkolů klienta, jako je synchronizace řetězce, a používají se pouze při prvním spuštění klienta. + +Protokol používaný pro interakce mezi uzlem a bootnodem je upravenou formou [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f), která používá [distribuovanou hašovací tabulku](https://en.wikipedia.org/wiki/Distributed_hash_table) ke sdílení seznamů uzlů. Každý uzel má verzi této tabulky obsahující informace potřebné k připojení k nejbližším kolegům. Tato „blízkost“ není geografická – vzdálenost je definována podobností ID uzlu. Tabulka každého uzlu je pravidelně obnovována jako bezpečnostní opatření. Například v protokolu pro objevování [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) mohou uzly také posílat „inzeráty“, které zobrazují subprotokoly, které klient podporuje, což umožňuje peerům vyjednávat o protokolech, které mohou oba použít ke vzájemné komunikaci. + +Objevování začíná hrou PING-PONG. Úspěšné PING-PONG „spojí“ nový uzel s bootnodem. Počáteční zpráva, která upozorní bootnode na existenci nového uzlu vstupujícího do sítě, je `PING`. Tento `PING` obsahuje hašované informace o novém uzlu, bootnodu a časové razítko expirace. Bootnode obdrží `PING` a vrátí `PONG` obsahující haš zprávy `PING`. Pokud se haše `PING` a `PONG` shodují, je spojení mezi novým uzlem a bootnodem ověřeno a říká se, že jsou „propojeni“. + +Po propojení může nový uzel poslat bootnodu požadavek `FIND-NEIGHBOURS`. Data vrácená bootnodem zahrnují seznam peerů, ke kterým se nový uzel může připojit. Pokud uzly nejsou propojeny, požadavek `FIND-NEIGHBOURS` selže a nový uzel tak nebude moci vstoupit do sítě. + +Jakmile nový uzel obdrží seznam sousedů od bootnodu, zahájí s každým z nich výměnu PING-PONG. Úspěšné PING-PONGy spojují nový uzel s jeho sousedy a umožňují výměnu zpráv. + +``` +spustit klienta --> připojit se k bootnodu --> propojit se s bootnodem --> najít sousedy --> propojit se se sousedy +``` + +Exekuční klienti v současné době používají protokol pro objevování [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) a aktivně se pracuje na migraci na protokol [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5). + +#### ENR: Ethereum Node Records {#enr} + +[Záznam o uzlu Ethereum (ENR)](/developers/docs/networking-layer/network-addresses/) je objekt, který obsahuje tři základní prvky: podpis (haš obsahu záznamu vytvořený podle dohodnutého schématu identity), pořadové číslo, které sleduje změny v záznamu, a libovolný seznam párů klíč:hodnota. Jedná se o formát, který je připraven na budoucnost a umožňuje snazší výměnu identifikačních informací mezi novými peery a je preferovaným formátem [síťové adresy](/developers/docs/networking-layer/network-addresses) pro uzly sítě Ethereum. + +#### Proč je objevování postaveno na UDP? Proč UDP? {#why-udp} + +UDP nepodporuje žádné kontrolní mechanismy chyb, opakované odesílání neúspěšných paketů ani dynamické otevírání a zavírání spojení – místo toho jen posílá nepřetržitý tok informací na cíl, bez ohledu na to, zda je úspěšně přijat. Tato minimální funkcionalita se také promítá do minimální režie, což činí tento typ spojení velmi rychlým. Pro objevování, kde uzel prostě chce oznámit svou přítomnost, aby pak mohl navázat formální spojení s peerem, je UDP dostačující. Pro zbytek síťové vrstvy však UDP není vhodné. Výměna informací mezi uzly je poměrně složitá a proto potřebuje plně vybavený protokol, který podporuje opakované odesílání, kontrolu chyb atd. Dodatečná režie spojená s TCP stojí za tuto dodatečnou funkcionalitu. Proto většina P2P stacku funguje přes TCP. + +### DevP2P {#devp2p} + +DevP2P je sada protokolů, které Ethereum implementuje k vytvoření a udržování peer-to-peer sítě. Poté, co nové uzly vstoupí do sítě, jsou jejich interakce řízeny protokoly ve stacku [DevP2P](https://github.com/ethereum/devp2p). Ty všechny běží na protokolu TCP a zahrnují transportní protokol RLPx, wire protokol a několik subprotokolů. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) je protokol, který řídí navazování, autentizaci a udržování relací mezi uzly. RLPx kóduje zprávy pomocí RLP (Recursive Length Prefix), což je velmi prostorově úsporná metoda kódování dat do minimální struktury pro odesílání mezi uzly. + +Relace RLPx mezi dvěma uzly začíná úvodním kryptografickým "podáním ruky". To zahrnuje uzel, který odesílá ověřovací zprávu, která je následně ověřena peerem. Při úspěšném ověření peer generuje ověřovací zprávu, kterou vrátí iniciátorskému uzlu. Toto je proces výměny klíčů, který umožňuje uzlům komunikovat soukromě a bezpečně. Úspěšné kryptografické podání ruky poté spustí oba uzly, aby si mezi sebou "na drátu" poslaly zprávu "hello". Wire protokol je zahájen úspěšnou výměnou zprávy "hello". + +Zprávy hello obsahují: + +- verzi protokolu +- ID klienta +- port +- ID uzlu +- seznam podporovaných subprotokolů + +Toto jsou informace potřebné pro úspěšnou interakci, protože definují, jaké schopnosti jsou sdíleny mezi oběma uzly, a konfigurují komunikaci. Tak probíhá proces vyjednávání subprotokolů, kde jsou porovnávány seznamy subprotokolů podporovaných každým uzlem a ty, které jsou společné oběma uzlům, mohou být použity v relaci. + +Spolu se zprávami hello může wire protokol také odeslat zprávu "disconnect", která upozorní kolegu, že spojení bude uzavřeno. Wire protokol také zahrnuje zprávy PING a PONG, které jsou pravidelně odesílány k udržení otevřené relace. Výměny RLPx a wire protokolu tedy vytvářejí základy komunikace mezi uzly a poskytují rámec pro výměnu užitečných informací podle specifického subprotokolu. + +### Subprotokoly {#sub-protocols} + +#### Wire protokol {#wire-protocol} + +Jakmile jsou peery připojeny a relace RLPx je spuštěna, wire protokol definuje, jakým způsobem peery komunikují. Původně wire protokol definoval tři hlavní úkoly: synchronizaci řetězce, šíření bloků a výměnu transakcí. Nicméně, jakmile Ethereum přešlo na proof of stake, šíření bloků a synchronizace řetězce se staly součástí konsensuální vrstvy. Výměna transakcí však stále spadá do působnosti exekučních klientů. Výměna transakcí se týká výměny nevyřízených transakcí mezi uzly, aby blokoví producenti mohli vybrat některé z nich k zařazení do dalšího bloku. Podrobné informace o těchto úkolech jsou k dispozici [zde](https://github.com/ethereum/devp2p/blob/master/caps/eth.md). Klienti, kteří tyto subprotokoly podporují, je zpřístupňují prostřednictvím [JSON-RPC](/developers/docs/apis/json-rpc/). + +#### les (light Ethereum subprotocol) {#les} + +Toto je minimální protokol pro synchronizaci jednoduchých uzlů. Tradičně byl tento protokol zřídka používán, protože úplné uzly jsou požadovány k poskytování dat jednoduchým uzlům bez pobídek. Výchozí chování exekučních klientů je neposkytovat data jednoduchým uzlům přes "les". Více informací je k dispozici ve [specifikaci](https://github.com/ethereum/devp2p/blob/master/caps/les.md) protokolu les. + +#### Snap {#snap} + +[Protokol snap](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) je volitelné rozšíření, které umožňuje peerům vyměňovat si snímky nedávných stavů, což peerům umožňuje ověřovat data účtu a úložiště bez nutnosti stahovat mezilehlé uzly Merkle trie. + +#### Wit (witness protocol) {#wit} + +[Protokol witness](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) je volitelné rozšíření, které umožňuje výměnu stavových svědků mezi peery a pomáhá synchronizovat klienty na nejnovější blok řetězce. + +#### Whisper {#whisper} + +Whisper byl protokol, který měl za cíl poskytovat bezpečné zprávy mezi peery, aniž by zapisoval jakékoli informace na blockchain. Byl součástí wire protokolu DevP2P, ale nyní je zastaralý. Existují i další [související projekty](https://wakunetwork.com/) s podobnými cíli. + +## Konsensuální vrstva {#consensus-layer} + +Konsensuální klienti se účastní samostatné peer-to-peer sítě s odlišnou specifikací. Konsensuální klienti se potřebují účastnit gossipu bloků, aby mohli přijímat nové bloky od kolegů a šířit je, když jsou na řadě v navrhování bloku. Podobně jako u exekuční vrstvy, toto nejprve vyžaduje objevovací protokol, aby uzel mohl najít peery a vytvořit zabezpečené relace pro výměnu bloků, potvrzení atd. + +### Objevování {#consensus-discovery} + +Podobně jako exekuční klienti používají i konsensuální klienti pro vyhledávání peerů protokol [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5) přes UDP. Implementace protokolu discv5 na konsensuální vrstvě se liší od implementace exekučních klientů pouze v tom, že obsahuje adaptér propojující discv5 se stackem [libP2P](https://libp2p.io/), čímž se DevP2P stává zastaralým. RLPx relace v exekuční vrstvě jsou nahrazeny zabezpečeným kanálem libP2P noise. + +### ENR {#consensus-enr} + +ENR pro konsensuální uzly obsahuje veřejný klíč uzlu, IP adresu, porty UDP a TCP a dvě pole specifická pro konsensus: bitové pole atestačního subnetu a klíč `eth2`. První z nich usnadňuje uzlům najít peery účastnící se specifických gossip subnetů pro potvrzení. Klíč `eth2` obsahuje informace o tom, jakou verzi větve (fork) Etherea uzel používá, což zajišťuje, že se peery připojují ke správnému Ethereu. + +### libP2P {#libp2p} + +LibP2P stack podporuje veškerou komunikaci po objevení. Klienti mohou volat a poslouchat na IPv4 a/nebo IPv6, jak je definováno v jejich ENR. Protokoly na vrstvě libP2P mohou být rozděleny do domén gossip a req/resp. + +### Gossip {#gossip} + +Doména gossip zahrnuje veškeré informace, které musí být rychle rozšířeny po síti. To zahrnuje beacon bloky, důkazy, potvrzení, výstupy a penalty. Toto je přenášeno pomocí libP2P gossipsub v1 a spoléhá na různá metadata, která jsou lokálně uložena na každém uzlu, včetně maximální velikosti gossip payloadů k přijímání a přenosu. Podrobné informace o gossip doméně jsou k dispozici [zde](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). + +### Požadavek–odpověď {#request-response} + +Doména request-response obsahuje protokoly, které umožňují klientům požadovat specifické informace od svých kolegů. Příklady zahrnují žádosti o konkrétní Beacon bloky, které odpovídají určitým kořenovým hashům nebo jsou v rozmezí určitých slotů. Odpovědi jsou vždy vráceny jako snappy-komprimované SSZ zakódované bajty. + +## Proč dává konsensuální klient přednost SSZ před RLP? {#ssz-vs-rlp} + +SSZ znamená simple serialization (jednoduchá serializace). Používá pevné offsety, které usnadňují dekódování jednotlivých částí zakódované zprávy, aniž by bylo nutné dekódovat celou strukturu, což je pro konsensuálního klienta velmi užitečné, protože umožňuje efektivně vyzvednout specifické části informací ze zakódovaných zpráv. SSZ je také navrženo speciálně pro integraci s Merkle protokoly, což přináší související zisky v efektivitě merkleizace. Vzhledem k tomu, že všechny hashe v konsensuální vrstvě jsou Merkle kořeny, jedná se o významné zlepšení. SSZ také zaručuje jedinečné reprezentace hodnot. + +## Propojení exekučních a konsensuálních klientů {#connecting-clients} + +Konsensuální i exekuční klienti běží paralelně. Potřebují být propojeni tak, aby konsensuální klient mohl poskytovat pokyny exekučnímu klientovi a exekuční klient mohl předávat balíky transakcí konsensuálnímu klientovi k zařazení do Beacon bloků. Komunikace mezi těmito dvěma klienty může být realizována pomocí lokálního RPC spojení. API známé jako ['Engine-API'](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) definuje instrukce posílané mezi těmito dvěma klienty. Vzhledem k tomu, že oba klienti fungují pod jednou síťovou identitou, sdílejí jeden ENR (Ethereum node record), který obsahuje samostatný klíč pro každého klienta (eth1 klíč a eth2 klíč). + +Souhrn toku řízení je uveden níže, s relevantní síťovou vrstvou v závorkách. + +### Když konsensuální klient není producentem bloku: {#when-consensus-client-is-not-block-producer} + +- Konsensuální klient přijme blok prostřednictvím block gossip protokolu (konsensuální p2p) +- Konsensuální klient předběžně validuje blok, tj. zajišťuje, že přišel od platného odesílatele se správnými metadaty. +- Transakce v bloku jsou odeslány do exekuční vrstvy jako exekuční payload (lokální RPC spojení) +- Exekuční vrstva provede transakce a zvaliduje stav v hlavičce bloku (tj. zkontroluje, zda se shodují haše). +- Exekuční vrstva předává validační data zpět konsensuální vrstvě, blok je nyní považován za validovaný (lokální RPC spojení) +- Konsensuální vrstva přidá blok na svůj vlastní blockchain a potvrzuje ho, přičemž vysílá potvrzení po síti (konsensuální p2p) + +### Když je konsensuální klient producentem bloku: {#when-consensus-client-is-block-producer} + +- Konsensuální klient dostane oznámení, že je dalším producentem bloku (konsensuální p2p) +- Konsensuální vrstva volá metodu `create block` v exekučním klientovi (místní RPC). +- Exekuční vrstva přistupuje k transakčnímu mempoolu, který byl naplněn prostřednictvím transakčního gossip protokolu (exekuční p2p) +- Exekuční klient shromažďuje transakce do bloku, provádí transakce a generuje hash bloku +- Konsensuální klient uchopí transakce a hash bloku od exekučního klienta a přidá je do beacon bloku (lokální RPC) +- Konsensuální klient vysílá blok prostřednictvím block gossip protokolu (konsensuální p2p) +- Ostatní klienti přijímají navržený blok prostřednictvím block gossip protokolu a validují ho, jak je popsáno výše (konsensuální p2p) + +Jakmile je blok potvrzen dostatečným počtem validátorů, je přidán na hlavu řetězce, ospravedlněn a nakonec finalizován. + +![](cons_client_net_layer.png)\n![](exe_client_net_layer.png) + +Schéma síťové vrstvy pro konsensuální a exekuční klienty, z [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) + +## Další čtení {#further-reading} + +[DevP2P](https://github.com/ethereum/devp2p)\n[LibP2p](https://github.com/libp2p/specs)\n[Specifikace sítě konsensuální vrstvy](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure)\n[Od Kademlia k Discv5](https://vac.dev/kademlia-to-discv5)\n[Článek o Kademlia](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf)\n[Úvod do P2P sítě Etherea](https://p2p.paris/en/talks/intro-ethereum-networking/)\n[Vztah eth1/eth2](http://ethresear.ch/t/eth1-eth2-client-relationship/7248)\n[Video s podrobnostmi o klientech pro sloučení a eth2](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/cs/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/cs/developers/docs/networking-layer/network-addresses/index.md new file mode 100644 index 00000000000..ca7d334d891 --- /dev/null +++ b/public/content/translations/cs/developers/docs/networking-layer/network-addresses/index.md @@ -0,0 +1,39 @@ +--- +title: "Síťové adresy" +description: "Úvod do síťových adres." +lang: cs +sidebarDepth: 2 +--- + +Síťové uzly se musí identifikovat pomocí základních informací, aby se mohly připojit k peerům. Aby se zajistilo, že jakýkoli potenciální peer může tyto informace interpretovat, jsou předávány v jednom ze tří standardizovaných formátů, kterým rozumí každý Ethereum uzel: multiaddr, enode nebo Ethereum Node Records (ENR). ENR jsou současným standardem pro síťové adresy na Ethereu. + +## Předpoklady {#prerequisites} + +Pro pochopení této stránky je nutná určitá znalost [síťové vrstvy](/developers/docs/networking-layer/) Etherea. + +## Multiaddr {#multiaddr} + +Původní formát adresy síťového uzlu Etherea byl 'multiaddr' (zkratka pro 'multi-adresy'). Multiaddr je univerzální formát navržený pro sítě peer-to-peer. Adresy jsou reprezentovány jako páry klíč-hodnota, kde jsou klíče a hodnoty odděleny lomítkem. Například multiaddr pro uzel s IPv4 adresou `192.168.22.27`, který naslouchá na TCP portu `33000`, vypadá takto: + +`/ip4/192.168.22.27/tcp/33000` + +Pro Ethereum uzel obsahuje multiaddr node-ID (haš veřejného klíče): + +`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` + +## Enode {#enode} + +Enode je způsob, jak identifikovat Ethereum uzel pomocí formátu URL adresy. Hexadecimální node-ID je zakódováno v uživatelské části URL, oddělené od hostitele znakem @. Hostitelské jméno může být zadáno pouze jako IP adresa; DNS jména nejsou povolena. Port v části hostitelského jména je TCP naslouchací port. Pokud se TCP a UDP (discovery) porty liší, UDP port je specifikován jako dotazovací parametr "discport". + +V následujícím příkladu URL uzlu popisuje uzel s IP adresou `10.3.58.6`, TCP portem `30303` a UDP discovery portem `30301`. + +`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` + +## Záznamy ethereových uzlů (ENR) {#enr} + +Ethereum Node Records (ENR) jsou standardizovaným formátem síťových adres na Ethereu. Nahrazují formáty multiaddr a enode. Tyto záznamy jsou obzvláště užitečné, protože umožňují větší výměnu informací mezi uzly. ENR obsahuje podpis, pořadové číslo a pole podrobně popisující identifikační schéma použité k vytvoření a ověření podpisů. ENR může být také naplněn libovolnými daty organizovanými jako páry klíč-hodnota. Tyto páry klíč-hodnota obsahují IP adresu uzlu a informace o podprotokolech, které uzel může používat. Konsensuální klienti používají [specifickou strukturu ENR](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) k identifikaci bootovacích uzlů a také obsahují pole `eth2` s informacemi o aktuální větvi Etherea a atestačním gossip subnetu (to propojuje uzel s konkrétní sadou peerů, jejichž atestace jsou agregovány dohromady). + +## Další čtení {#further-reading} + +- [EIP-778: Záznamy ethereových uzlů (ENR)](https://eips.ethereum.org/EIPS/eip-778) +- [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/cs/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/cs/developers/docs/networking-layer/portal-network/index.md new file mode 100644 index 00000000000..7df3d36c484 --- /dev/null +++ b/public/content/translations/cs/developers/docs/networking-layer/portal-network/index.md @@ -0,0 +1,89 @@ +--- +title: The Portal Network +description: "Přehled sítě Portal Network - sítě ve vývoji, navržené pro podporu nízkozdrojových klientů." +lang: cs +--- + +Ethereum je síť složená z počítačů, které provozují softwarové klienty Etherea. Každý z těchto počítačů se nazývá síťový „uzel“. Klientský software umožňuje uzlu odesílat a přijímat data v síti Ethereum a ověřovat data podle pravidel protokolu Etherea. Uzel uchovává velké množství historických dat na svém disku a přidává další, když přijme nové informační pakety, známé jako bloky, od ostatních uzlů v síti. To je nutné pro neustálou kontrolu, zda má uzel informace konzistentní se zbytkem sítě. To znamená, že provozování uzlu může vyžadovat hodně prostoru na disku. Některé operace uzlu mohou vyžadovat také hodně RAM. + +Aby se tento problém s prostorem vyřešil, byly vyvinuty „jednoduché“ uzly, které požadují informace od úplných uzlů, místo aby je všechny uchovávaly samy. To však znamená, že jednoduchý uzel nezávisle neověřuje informace a místo toho důvěřuje jinému uzlu. Znamená to také, že úplné uzly musí vykonávat dodatečnou práci, aby těmto jednoduchým uzlům poskytly potřebná data. + +Portal Network je nový síťový design pro Ethereum, který si klade za cíl vyřešit problém dostupnosti dat pro „jednoduché“ uzly, aniž by bylo nutné důvěřovat úplným uzlům nebo na ně klást další zátěž, sdílením potřebných dat v malých kouscích napříč sítí. + +Více o [uzlech a klientech](/developers/docs/nodes-and-clients/) + +## Proč potřebujeme síť Portal {#why-do-we-need-portal-network} + +Síťové uzly na Ethereu uchovávají vlastní plnou nebo částečnou kopii blockchainu Etherea. Tato lokální kopie slouží k validaci transakcí a zajištění, že uzel sleduje správný řetězec. Tato lokálně uložená data umožňují síťovým uzlům nezávisle ověřovat, že příchozí data jsou platná a správná, aniž by musely důvěřovat jakékoli jiné entitě. + +Tato lokální kopie blockchainu a s ní spojená stavová a potvrzovací data zabírají na pevném disku uzlu hodně místa. Například pro spuštění uzlu pomocí [Geth](https://geth.ethereum.org) spárovaného s konsensuálním klientem se doporučuje 2TB pevný disk. Při použití snap syncu, který ukládá data řetězce pouze z relativně nedávné sady bloků, obvykle Geth zabírá asi 650 GB diskového prostoru, ale roste přibližně o 14 GB týdně (uzel můžete pravidelně snižovat úschovu zpět na 650 GB). + +To znamená, že provozování síťových uzlů může být nákladné, protože velké množství diskového prostoru musí být vyhrazeno pro Ethereum. V plánu Ethereum existuje několik řešení tohoto problému, včetně [vypršení historie](/roadmap/statelessness/#history-expiry), [vypršení stavu](/roadmap/statelessness/#state-expiry) a [bezstavovosti](/roadmap/statelessness/). Tato řešení jsou však pravděpodobně od implementace vzdálena několik let. Existují také [lehké uzly](/developers/docs/nodes-and-clients/light-clients/), které neukládají vlastní kopii dat řetězce, ale vyžadují data, která potřebují, od plných uzlů. To však znamená, že jednoduché uzly musí důvěřovat úplným uzlům, že poskytnou poctivá data, a zároveň zatěžují úplné uzly, které musí tato data poskytovat. + +Portal Network si klade za cíl poskytnout alternativní způsob, jak mohou jednoduché uzly získat svá data, aniž by musely důvěřovat úplným uzlům nebo výrazně přispívat k práci, kterou musí úplné uzly vykonávat. Tento cíl bude dosažen zavedením nového způsobu, jak mohou uzly Etherea sdílet data napříč sítí. + +## Jak funguje Portal Network? {#how-does-portal-network-work} + +Síťové uzly na Ethereu mají přísné protokoly, které definují, jak spolu komunikují. Exekuční klienti komunikují pomocí sady subprotokolů známých jako [DevP2P](/developers/docs/networking-layer/#devp2p), zatímco konsensuální klienti používají jinou sadu subprotokolů nazvanou [libP2P](/developers/docs/networking-layer/#libp2p). Tyto protokoly definují typy dat, která mohou být mezi uzly předávána. + +![devP2P a libP2P](portal-network-devp2p-libp2p.png) + +Uzly mohou také poskytovat specifická data prostřednictvím [JSON-RPC API](/developers/docs/apis/json-rpc/), což je způsob, jakým si aplikace a peněženky vyměňují informace s uzly Ethereum. Nicméně, žádný z těchto protokolů není ideální pro poskytování dat jednoduchým klientům. + +Jednoduché uzly aktuálně nemohou požadovat konkrétní části dat řetězce přes DevP2P nebo libP2p, protože tyto protokoly jsou navrženy pouze pro synchronizaci řetězce a šíření bloků a transakcí. Jednoduché uzly nechtějí tato data stahovat, protože by to narušilo jejich jednoduchost. + +JSON-RPC API také není ideální volbou pro požadavky na data vyslaná od jednoduchými klienty, protože spoléhá na připojení ke konkrétnímu úplnému uzlu nebo centralizovanému poskytovateli RPC, který může tato data sdílet. To znamená, že jednoduchý klient musí důvěřovat tomuto konkrétnímu uzlu nebo poskytovateli, že bude poctivý, a také úplný uzel může být zatížen množstvím požadavků od mnoha jednoduchých klientů, což zvyšuje jeho nároky na šířku pásma. + +Cílem sítě Portal Network je znovu promyslet celý design, s důrazem na jednoduchost, mimo omezení existujících Ethereum klientů. + +Hlavní myšlenkou sítě Portal je vzít to nejlepší ze současného síťového stacku tím, že umožní, aby informace potřebné pro lehké klienty, jako jsou historická data a identita aktuální hlavy řetězce, byly obsluhovány prostřednictvím odlehčené, decentralizované peer-to-peer sítě ve stylu DevP2P s využitím [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table) (podobně jako Bittorrent). + +Idea je přidat malé části celkových historických dat Etherea a určité specifické uzlové odpovědnosti každému uzlu. Poté jsou požadavky obsluhovány tím, že se vyhledají síťové uzly uchovávající požadovaná data a tato data se od nich získají. + +Tento přístup obrací normální model, kdy jednoduché uzly vyhledávají jediný uzel a požadují po něm filtrování a poskytování velkých objemů dat; místo toho rychle filtrují velkou síť uzlů, z nichž každý zpracovává malé množství dat. + +Cílem je umožnit decentralizované síti jednoduchých Portal klientů: + +- sledovat hlavičku řetězce +- synchronizovat nedávná a historická data řetězce +- získávat stavová data +- vysílat transakce +- provádět transakce pomocí [EVM](/developers/docs/evm/) + +Výhody tohoto síťového designu jsou: + +- snížení závislosti na centralizovaných poskytovatelích +- Snížení využití internetové šířky pásma +- Minimální nebo žádná synchronizace +- Přístupné pro zařízení s omezenými zdroji (\<1 GB RAM, \<100 MB místa na disku, 1 CPU) + +Níže uvedená tabulka ukazuje funkce stávajících klientů, které může poskytovat síť Portal, což uživatelům umožňuje přístup k těmto funkcím na zařízeních s velmi malými zdroji. + +### Sítě Portal + +| Lehký klient Beaconu | Stavová síť | Gossip transakcí | Historická síť | +| --------------------------- | --------------------- | ----------------- | -------------- | +| Lehká data pro Beacon Chain | Úložiště účtů a smluv | Odlehčený mempool | Hlavičky | +| Data protokolu | | | Těla bloků | +| | | | Potvrzení | + +## Diverzita klientů ve výchozím nastavení {#client-diversity-as-default} + +Vývojáři sítě Portal se také od prvního dne rozhodli vytvořit čtyři samostatné klienty sítě Portal. + +Klienti sítě Portal Network jsou: + +- [Trin](https://github.com/ethereum/trin): napsaný v Rustu +- [Fluffy](https://fluffy.guide): napsaný v Nim +- [Ultralight](https://github.com/ethereumjs/ultralight): napsaný v Typescriptu +- [Shisui](https://github.com/zen-eth/shisui): napsaný v Go + +Mít více nezávislých implementací klientů zvyšuje odolnost a decentralizaci sítě Ethereum. + +Pokud by jeden klient měl problémy nebo zranitelnosti, ostatní klienti mohou nadále hladce fungovat, čímž se zabrání vzniku jediného bodu selhání. Různorodost implementací klientů navíc podporuje inovace a konkurenci, což vede k vylepšením a snižuje riziko monokultury v ekosystému. + +## Další čtení {#further-reading} + +- [Síť Portal (Piper Merriam na Devcon Bogota)](https://www.youtube.com/watch?v=0stc9jnQLXA). +- [Discord sítě Portal](https://discord.gg/CFFnmE7Hbs) +- [Webové stránky sítě Portal](https://www.ethportal.net/) diff --git a/public/content/translations/cs/developers/docs/networks/index.md b/public/content/translations/cs/developers/docs/networks/index.md index cd11b69763e..252cc599d2c 100644 --- a/public/content/translations/cs/developers/docs/networks/index.md +++ b/public/content/translations/cs/developers/docs/networks/index.md @@ -1,28 +1,28 @@ --- -title: Sítě -description: Přehled sítí Etherea a návod, kde získat ether (ETH) testovací sítě pro testování vaší aplikace. +title: "Sítě" +description: "Přehled sítí Etherea a návod, kde získat ether (ETH) testovací sítě pro testování vaší aplikace." lang: cs --- -Sítě Etherea jsou skupiny propojených počítačů, které komunikují pomocí protokolu Ethereum. Existuje pouze jedna hlavní síť Etherea, ale nezávislé sítě, které dodržují stejná pravidla protokolu, mohou být vytvořeny pro testovací a vývojové účely. Existuje mnoho nezávislých "sítí", které dodržují protokol, aniž by mezi sebou komunikovaly. Můžete si dokonce spustit vlastní síť na svém počítači k testování chytrých kontraktů a web3 aplikací. +Sítě Etherea jsou skupiny propojených počítačů, které komunikují pomocí protokolu Ethereum. Existuje pouze jedna hlavní síť Etherea, ale nezávislé sítě, které dodržují stejná pravidla protokolu, mohou být vytvořeny pro testovací a vývojové účely. Existuje mnoho nezávislých „sítí“, které dodržují protokol, aniž by mezi sebou komunikovaly. Můžete si dokonce spustit vlastní síť na svém počítači k testování chytrých kontraktů a web3 aplikací. Váš účet na Ethereu bude fungovat na různých sítích, ale zůstatek na účtu a historie transakcí se nepřenesou z hlavní sítě Etherea. Pro testovací účely je užitečné vědět, které sítě jsou k dispozici a jak získat ETH testovací sítě, abyste mohli experimentovat. Obecně platí, že z bezpečnostních důvodů se nedoporučuje používat účty z hlavní sítě na testovacích sítích nebo naopak. ## Předpoklady {#prerequisites} -Předtím, než se začnete zabývat různými sítěmi, byste měli rozumět [základům Etherea](/developers/docs/intro-to-ethereum/), protože testovací sítě vám poskytnou levnou a bezpečnou verzi Etherea pro experimentování. +Než si začnete číst o různých sítích, měli byste porozumět [základům Etherea](/developers/docs/intro-to-ethereum/), protože testnety vám poskytnou levnou a bezpečnou verzi Etherea, se kterou si můžete hrát. ## Veřejné sítě {#public-networks} Veřejné sítě jsou přístupné komukoliv na světě s připojením k internetu. Každý může číst nebo vytvářet transakce na veřejném blockchainu a ověřovat prováděné transakce. Konsenzus mezi síťovými uzly rozhoduje o zahrnutí transakcí a stavu sítě. -### Hlavní síť Ethereum {#ethereum-mainnet} +### Mainnet Etherea {#ethereum-mainnet} Hlavní síť je primární veřejný produkční blockchain Etherea, kde dochází k transakcím s reálnou hodnotou na distribuované účetní knize. Když veřejnost nebo burzy diskutují o cenách ETH, mluví o ETH na hlavní síti. -### Testovací sítě Etherea {#ethereum-testnets} +### Testnety Etherea {#ethereum-testnets} Kromě hlavní sítě existují veřejné testovací sítě. Tyto sítě používají vývojáři protokolu nebo chytrých kontraktů k testování jak vylepšení protokolu, tak potenciálních chytrých kontraktů v prostředí podobném produkčnímu prostředí, než budou nasazeny na hlavní síť. Můžete si je představit jako analogii mezi produkčním a testovacím serverem. @@ -34,19 +34,15 @@ ETH na testovacích sítích nemá mít žádnou skutečnou hodnotu. Přesto vzn #### Kterou testovací síť bych měl/a použít? -Dvě veřejné testovací sítě, které aktuálně udržují vývojáři klientů, jsou Sepolia a Hoodi. Sepolia je síť pro vývojáře kontraktů a aplikací, kteří je chtějí otestovat. Síť Hoodi umožňuje vývojářům protokolu testovat vylepšení sítě a také umožňuje uzamykatelům zkoušet provozování validátorů. +Dva veřejné testnety, které vývojáři klientů v současné době udržují, jsou Sepolia a Hoodi. Sepolia je síť pro vývojáře kontraktů a aplikací, kteří je chtějí otestovat. Síť Hoodi umožňuje vývojářům protokolů testovat vylepšení sítě a stakerům testovat provoz validátorů. #### Sepolia {#sepolia} -**Sepolia je doporučená výchozí testovací síť pro vývoj aplikací**. Síť Sepolia používá povolenou sadu validátorů. Je poměrně nová, což znamená, že její stav a historie jsou stále celkem malé. To znamená, že síť se rychle synchronizuje a provozování uzlu na ní vyžaduje méně úložného prostoru. To je užitečné pro uživatele, kteří chtějí spustit uzel rychle a napřímo komunikovat se sítí. - -- Uzavřená sada validátorů, kontrolována týmy klientů a testerů -- Nová testovací síť, méně spuštěných aplikací než na jiných testovacích sítích -- Rychlá synchronizace, provoz uzlu vyžaduje minimální úložný prostor +**Sepolia je doporučená výchozí testovací síť pro vývoj aplikací**. Síť Sepolia používá sadu validátorů s oprávněními, která je kontrolovaná týmy klientů a testovacími týmy. ##### Zdroje -- [Web](https://sepolia.dev/) +- [Webové stránky](https://sepolia.dev/) - [GitHub](https://github.com/eth-clients/sepolia) - [Otterscan](https://sepolia.otterscan.io/) - [Etherscan](https://sepolia.etherscan.io) @@ -54,18 +50,20 @@ Dvě veřejné testovací sítě, které aktuálně udržují vývojáři klient ##### Faucety -- [QuickNode Sepolia Faucet](https://faucet.quicknode.com/drip) +- [Alchemy Sepolia Faucet](https://www.alchemy.com/faucets/ethereum-sepolia) +- [Chain Platform Sepolia Faucet](https://faucet.chainplatform.co/faucets/ethereum-sepolia/) +- [Chainstack Sepolia Faucet](https://faucet.chainstack.com/sepolia-testnet-faucet) +- [Faucet ekosystému Ethereum](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [ethfaucet.com Sepolia Faucet](https://ethfaucet.com/networks/ethereum) +- [Google Cloud Web3 Sepolia Faucet](https://cloud.google.com/application/web3/faucet/ethereum/sepolia) - [Grabteeth](https://grabteeth.xyz/) -- [PoW faucet](https://sepolia-faucet.pk910.de/) -- [Coinbase Wallet Faucet | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet) -- [Alchemy Sepolia faucet](https://sepoliafaucet.com/) -- [Infura Sepolia faucet](https://www.infura.io/faucet) -- [Chainstack Sepolia faucet](https://faucet.chainstack.com/sepolia-testnet-faucet) -- [Ethereum Ecosystem faucet](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) +- [Infura Sepolia Faucet](https://www.infura.io/faucet) +- [PoW Faucet](https://sepolia-faucet.pk910.de/) +- [QuickNode Sepolia Faucet](https://faucet.quicknode.com/ethereum/sepolia) #### Hoodi {#hoodi} -Hoodi je testovací síť pro testování validace a uzamčení. Síť Hoodi je otevřená uživatelům, kteří chtějí provozovat validátor na testovací síti. Uzamykatelé, kteří chtějí testovat vylepšení protokolu před jejich nasazením na hlavní síť, by proto měli používat Hoodi. +Hoodi je testnet pro testování validace a stakingu. Síť Hoodi je otevřená pro uživatele, kteří chtějí provozovat testnet validátor. Stakeři, kteří chtějí testovat vylepšení protokolu před jejich nasazením na mainnet, by proto měli používat Hoodi. - Otevřená sada validátorů, uzamykatelé mohou testovat vylepšení sítě - Obsáhlý stav, užitečné pro testování složitých interakcí chytrých kontraktů @@ -73,69 +71,146 @@ Hoodi je testovací síť pro testování validace a uzamčení. Síť Hoodi je ##### Zdroje -- [Web](https://hoodi.ethpandaops.io/) +- [Webové stránky](https://hoodi.ethpandaops.io/) - [GitHub](https://github.com/eth-clients/hoodi) -- [Explorer](https://explorer.hoodi.ethpandaops.io/) +- [Průzkumník](https://explorer.hoodi.ethpandaops.io/) - [Checkpoint Sync](https://checkpoint-sync.hoodi.ethpandaops.io/) +- [Otterscan](https://hoodi.otterscan.io/) +- [Etherscan](https://hoodi.etherscan.io/) ##### Faucety +- [Chain Platform Hoodi Faucet](https://faucet.chainplatform.co/faucets/ethereum-hoodi/) - [Hoodi Faucet](https://hoodi.ethpandaops.io/) +- [PoW Faucet](https://hoodi-faucet.pk910.de/) + +#### Ephemery {#ephemery} + +Ephemery je jedinečný druh testnetu, který se každý měsíc plně resetuje. Exekuční a konsensuální stav se každých 28 dní vrací zpět do geneze, což znamená, že vše, co se na testnetu stane, je pomíjivé. Díky tomu je ideální pro krátkodobé testování, rychlý bootstrap uzlů a aplikace typu „hello world“, které nepotřebují stálost. + +- Vždy čerstvý stav, krátkodobé testování validátorů a aplikací +- Zahrnuje pouze základní sadu kontraktů +- Otevřená sada validátorů a snadný přístup k velkým finančním částkám +- Nejmenší požadavky na uzel a nejrychlejší synchronizace, v průměru <5 GB + +##### Zdroje + +- [Webové stránky](https://ephemery.dev/) +- [Github](https://github.com/ephemery-testnet/ephemery-resources) +- [Komunitní chat](https://matrix.to/#/#staker-testnet:matrix.org) +- [Blockscout](https://explorer.ephemery.dev/) +- [Otterscan](https://otter.bordel.wtf/) +- [Průzkumník Beacon](https://beaconlight.ephemery.dev/) +- [Checkpoint Sync](https://checkpoint-sync.ephemery.ethpandaops.io) +- [Launchpad](https://launchpad.ephemery.dev/) -Ke spuštění validátoru na testovací síti Hoodi použijte [Hoodi launchpad](https://hoodi.launchpad.ethereum.org/en/). +#### Faucety -### Testovací sítě druhé vrstvy {#layer-2-testnets} +- [Bordel Faucet](https://faucet.bordel.wtf/) +- [Pk910 PoW Faucet](https://ephemery-faucet.pk910.de/) -[Druhá vrstva (L2)](/layer-2/) je souhrnný termín pro popis specifických sad škálovacích řešení Etherea. Druhá vrstva je samostatný blockchain, který rozšiřuje Ethereum a dědí jeho bezpečnostní záruky. Testovací sítě druhé vrstvy jsou obvykle úzce spojeny s veřejnými testovacími sítěmi Etherea. +#### Holesky (zastaralý) {#holesky} + +Testnet Holesky je od září 2025 zastaralý. Provozovatelé stakingu a poskytovatelé infrastruktury by místo toho měli pro testování validátorů používat Hoodi. + +- [Oznámení o ukončení provozu testnetu Holesky](https://blog.ethereum.org/2025/09/01/holesky-shutdown-announcement) – _Blog EF, 1. září 2025_ +- [Aktualizace testnetů Holesky a Hoodi](https://blog.ethereum.org/en/2025/03/18/hoodi-holesky) – _Blog EF, 18. března 2025_ + +### Testnety druhé vrstvy {#layer-2-testnets} + +[Druhá vrstva (L2)](/layer-2/) je souhrnný termín popisující specifickou sadu řešení pro škálování Etherea. Druhá vrstva je samostatný blockchain, který rozšiřuje Ethereum a dědí jeho bezpečnostní záruky. Testovací sítě druhé vrstvy jsou obvykle úzce spojeny s veřejnými testovacími sítěmi Etherea. #### Arbitrum Sepolia {#arbitrum-sepolia} -Testovací síť pro [Arbitrum](https://arbitrum.io/). +Testnet pro [Arbitrum](https://arbitrum.io/). + +##### Zdroje + +- [Etherscan](https://sepolia.arbiscan.io/) +- [Blockscout](https://sepolia-explorer.arbitrum.io/) ##### Faucety -- [Chainlink faucet](https://faucets.chain.link/arbitrum-sepolia) -- [Alchemy faucet](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Alchemy Arbitrum Sepolia Faucet](https://www.alchemy.com/faucets/arbitrum-sepolia) +- [Chainlink Arbitrum Sepolia faucet](https://faucets.chain.link/arbitrum-sepolia) +- [ethfaucet.com Arbitrum Sepolia Faucet](https://ethfaucet.com/networks/arbitrum) +- [QuickNode Arbitrum Sepolia Faucet](https://faucet.quicknode.com/arbitrum/sepolia) #### Optimistic Sepolia {#optimistic-sepolia} -Testovací síť pro [Optimism](https://www.optimism.io/). +Testnet pro [Optimism](https://www.optimism.io/). + +##### Zdroje + +- [Etherscan](https://sepolia-optimistic.etherscan.io/) +- [Blockscout](https://optimism-sepolia.blockscout.com/) ##### Faucety -- [Chainlink faucet](https://faucets.chain.link/optimism-sepolia) -- [Alchemy faucet](https://www.alchemy.com/faucets/optimism-sepolia) +- [Alchemy Faucet](https://www.alchemy.com/faucets/optimism-sepolia) +- [Chainlink Faucet](https://faucets.chain.link/optimism-sepolia) +- [ethfaucet.com Optimism Sepolia Faucet](https://ethfaucet.com/networks/optimism) +- [Testnet Faucet](https://docs.optimism.io/builders/tools/build/faucets) #### Starknet Sepolia {#starknet-sepolia} -Testovací síť pro [Starknet](https://www.starknet.io). +Testnet pro [Starknet](https://www.starknet.io). + +##### Zdroje + +- [Starkscan](https://sepolia.starkscan.co/) ##### Faucety -- [Alchemy faucet](https://www.alchemy.com/faucets/starknet-sepolia) +- [Alchemy Faucet](https://www.alchemy.com/faucets/starknet-sepolia) +- [Blast Starknet Sepolia Faucet](https://blastapi.io/faucets/starknet-sepolia-eth) +- [Starknet Faucet](https://starknet-faucet.vercel.app/) -## Privátní sítě {#private-networks} +## Soukromé sítě {#private-networks} -Síť Etherea je privátní, pokud její uzly nejsou připojeny k veřejné síti (tj. hlavní nebo testovací síť). V tomto kontextu znamená "privátní" pouze vyhrazená nebo izolovaná, spíše než chráněná nebo bezpečná. +Síť Etherea je soukromá síť, pokud její uzly nejsou připojeny k veřejné síti (tj. k mainnetu nebo testnetu). V tomto kontextu znamená „privátní“ pouze vyhrazená nebo izolovaná, spíše než chráněná nebo bezpečná. -### Vývojové sítě {#development-networks} +### Vývojářské sítě {#development-networks} Chcete-li vyvíjet aplikaci na Ethereu, budete ji chtít nejprve spustit na privátní síti, abyste viděli, jak funguje, než ji nasadíte. Podobně jako vytváříte lokální server na svém počítači pro vývoj webu, můžete vytvořit lokální instanci blockchainu pro testování vaší dappky. To umožňuje mnohem rychlejší iteraci než na veřejné testovací síti. -Existují projekty a nástroje, které vám s tím pomohou. Další informace o [vývojových sítích](/developers/docs/development-networks/). +Existují projekty a nástroje, které vám s tím pomohou. Přečtěte si více o [vývojářských sítích](/developers/docs/development-networks/). -### Konsorciové sítě {#consortium-networks} +### Konsorciální sítě {#consortium-networks} Proces konsenzu je řízen předem definovanou sadou důvěryhodných uzlů. Např. soukromá síť známých akademických institucí, z nichž každá spravuje jeden uzel, a bloky jsou ověřovány prahovým počtem signatářů v této síti. Pokud je veřejná síť Etherea jako veřejný internet, konsorciová síť je jako privátní intranet. +## Proč jsou testnety Etherea pojmenovány po stanicích metra? {#why-naming} + +Mnoho testnetů Etherea je pojmenováno po skutečných stanicích metra nebo vlakových nádražích. Tato tradice pojmenovávání začala brzy a odráží světová města, kde přispěvatelé žili nebo pracovali. Je to symbolické, zapamatovatelné a praktické. Stejně jako jsou testnety izolovány od mainnetu Etherea, linky metra jezdí odděleně od povrchové dopravy. + +### Běžně používané a starší testnety {#common-and-legacy-testnets} + +- **Sepolia** – Čtvrť v řeckých Aténách napojená na metro. V současné době se používá pro testování chytrých kontraktů a dApps. +- **Hoodi** – Pojmenováno po stanici metra Hoodi v indickém Bengalúru. Používá se pro testování validátorů a vylepšení protokolu. +- **Goerli** _(zastaralý)_ – Pojmenováno po nádraží Görlitzer Bahnhof v německém Berlíně. +- **Rinkeby** _(zastaralý)_ – Pojmenováno po předměstí Stockholmu se stanicí metra. +- **Ropsten** _(zastaralý)_ – Odkazuje na oblast a bývalý terminál trajektů/metra ve Stockholmu. +- **Kovan** _(zastaralý)_ – Pojmenováno po stanici MRT v Singapuru. +- **Morden** _(zastaralý)_ – Pojmenováno po stanici londýnského metra. První veřejný testnet Etherea. + +### Ostatní specializované testnety {#other-testnets} + +Některé testnety byly vytvořeny pro krátkodobé nebo pro vylepšení specifické testování a nemusí být nutně s tématikou metra: + +- **Holesky** _(zastaralý)_ – Pojmenováno po stanici Holešovice v Praze. Používá se pro testování validátorů; zastaralý v roce 2025. +- **Kiln**, **Zhejiang**, **Shandong**, **Prater**, **Pyrmont**, **Olympic** _(všechny zastaralé)_ a **Ephemery** – Účelově vytvořené pro simulace vylepšení, jako je Sloučení, Shanghai, nebo pro experimenty s validátory. Některé názvy jsou spíše regionální nebo tematické než založené na metru. + +Používání názvů stanic metra pomáhá vývojářům rychle identifikovat a zapamatovat si testnety, aniž by se museli spoléhat na číselné ID řetězců. Odráží také kulturu Etherea: praktickou, globální a zaměřenou na člověka. + ## Související nástroje {#related-tools} -- [Chainlist](https://chainlist.org/) _– seznam EVM sítí pro připojení peněženek a poskytovatelů k odpovídajícímu Chain ID a Network ID_ -- [EVM-based Chains](https://github.com/ethereum-lists/chains) _– repozitář na GitHubu obsahující metadata řetězců, která napájí Chainlist_ +- [Chainlist](https://chainlist.org/) _seznam EVM sítí pro připojení peněženek a poskytovatelů k odpovídajícímu Chain ID a Network ID_ +- [Řetězce založené na EVM](https://github.com/ethereum-lists/chains) _GitHub repozitář metadat řetězců, který pohání Chainlist_ -## Další informace {#further-reading} +## Další čtení {#further-reading} -- [Návrh: Předvídatelný životní cyklus testovací sítě Etherea](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) -- [Vývoj testovacích sítí Etherea](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) +- [Návrh: Předvídatelný životní cyklus testnetů Etherea](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) +- [Evoluce testnetů Etherea](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/archive-nodes/index.md new file mode 100644 index 00000000000..2f3b56f5a54 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -0,0 +1,81 @@ +--- +title: "Archivní uzel Etherea" +description: "Přehled archivních uzlů" +lang: cs +sidebarDepth: 2 +--- + +Archivní uzel je instancí klienta sítě Ethereum, který je nakonfigurován k vytvoření archivu všech historických stavů. Jedná se o užitečný nástroj pro určité případy použití, ale jeho provoz může být složitější než u plného uzlu. + +## Předpoklady {#prerequisites} + +Měli byste rozumět konceptu [uzlu sítě Ethereum](/developers/docs/nodes-and-clients/), [jeho architektuře](/developers/docs/nodes-and-clients/node-architecture/), [strategiím synchronizace](/developers/docs/nodes-and-clients/#sync-modes) a postupům pro jejich [provoz](/developers/docs/nodes-and-clients/run-a-node/) a [používání](/developers/docs/apis/json-rpc/). + +## Co je to archivní uzel + +Abychom pochopili důležitost archivního uzlu, objasněme si pojem "stav". O Ethereu lze mluvit jako o _stavovém automatu založeném na transakcích_. Skládá se z účtů a aplikací, které provádějí transakce měnící jejich stav. Globální data s informacemi o každém účtu a kontraktu jsou uložena v databázi trie nazývané stav. O to se stará klient exekuční vrstvy (EL) a zahrnuje to: + +- Zůstatky na účtech a hodnoty nonce +- Kód kontraktu a úložiště +- Data související s konsensem, např. vkladový kontrakt pro uzamčení + +Aby mohly interagovat se sítí, ověřovat a vytvářet nové bloky, musí klienti Etherea držet krok s nejnovějšími změnami (špičkou řetězce), a tedy i s aktuálním stavem. Klient exekuční vrstvy nakonfigurovaný jako plný uzel ověřuje a sleduje nejnovější stav sítě, ale do mezipaměti ukládá pouze několik posledních stavů, např. stav spojený s posledními 128 bloky, aby mohl zpracovávat reorganizace řetězce a poskytovat rychlý přístup k nejnovějším datům. Poslední stav je to, co všichni klienti potřebují k ověření příchozích transakcí a používání sítě. + +Stav si můžete představit jako okamžitý snímek sítě v daném bloku a archiv jako přehrání historie. + +Historické stavy mohou být bezpečně odstraněny, protože nejsou nutné pro fungování sítě a bylo by zbytečně redundantní, aby si klient ponechával všechna zastaralá data. Stavy, které existovaly před nějakým nedávným blokem (např. 128 bloků před špičkou), jsou v podstatě zahozeny. Plné uzly uchovávají pouze historická data blockchainu (bloky a transakce) a příležitostné historické snímky, které mohou na požádání použít k obnovení starších stavů. Dělají to tak, že znovu provádějí minulé transakce v EVM, což může být výpočetně náročné, když je požadovaný stav daleko od nejbližšího snímku. + +To však znamená, že přístup k historickému stavu na plném uzlu spotřebuje mnoho výpočetního výkonu. Klient může potřebovat provést všechny minulé transakce a vypočítat jeden historický stav od geneze. Archivní uzly to řeší tím, že ukládají nejen nejnovější stavy, ale všechny historické stavy vytvořené po každém bloku. V podstatě se jedná o kompromis s většími požadavky na místo na disku. + +Je důležité si uvědomit, že síť nezávisí na archivních uzlech, které by uchovávaly a poskytovaly všechna historická data. Jak již bylo zmíněno, všechny historické přechodné stavy lze odvodit na plném uzlu. Transakce jsou uloženy na každém plném uzlu (v současnosti méně než 400 GB) a lze je znovu přehrát a vytvořit tak celý archiv. + +### Případy použití + +Běžné používání Etherea, jako je odesílání transakcí, nasazování kontraktů, ověřování konsensu atd., nevyžaduje přístup k historickým stavům. Uživatelé nikdy nepotřebují archivní uzel pro standardní interakci se sítí. + +Hlavní výhodou stavového archivu je rychlý přístup k dotazům na historické stavy. Archivní uzel by například okamžitě vrátil výsledky jako: + +- _Jaký byl zůstatek ETH na účtu 0x1337... v bloku 15537393?_ +- _Jaký je zůstatek tokenu 0x v kontraktu 0x v bloku 1920000?_ + +Jak bylo vysvětleno výše, plný uzel by musel tato data generovat provedením EVM, které využívá procesor a zabere čas. Archivní uzly k nim přistupují na disku a okamžitě poskytují odpovědi. Jedná se o užitečnou funkci pro určité části infrastruktury, například: + +- Poskytovatelé služeb, jako jsou prohlížeče bloků +- Výzkumníci +- Bezpečnostní analytici +- Vývojáři dapp +- Audit a dodržování předpisů + +Existují různé bezplatné [služby](/developers/docs/nodes-and-clients/nodes-as-a-service/), které také umožňují přístup k historickým datům. Vzhledem k tomu, že provoz archivního uzlu je náročnější, je tento přístup většinou omezený a funguje pouze pro příležitostný přístup. Pokud váš projekt vyžaduje neustálý přístup k historickým datům, měli byste zvážit provoz vlastního uzlu. + +## Implementace a použití + +Archivní uzel v tomto kontextu znamená data poskytovaná klienty exekuční vrstvy, kteří se starají o databázi stavů a poskytují koncové body JSON-RPC. Možnosti konfigurace, doba synchronizace a velikost databáze se mohou u jednotlivých klientů lišit. Podrobnosti naleznete v dokumentaci poskytnuté vaším klientem. + +Než spustíte vlastní archivní uzel, seznamte se s rozdíly mezi klienty a zejména s různými [hardwarovými požadavky](/developers/docs/nodes-and-clients/run-a-node/#requirements). Většina klientů není pro tuto funkci optimalizována a jejich archivy vyžadují více než 12 TB místa. Naproti tomu implementace jako Erigon mohou ukládat stejná data na méně než 3 TB, což z nich činí nejefektivnější způsob provozu archivního uzlu. + +## Doporučené postupy + +Kromě obecných [doporučení pro provoz uzlu](/developers/docs/nodes-and-clients/run-a-node/) může být archivní uzel náročnější na hardware a údržbu. S ohledem na [klíčové funkce](https://github.com/ledgerwatch/erigon#key-features) Erigonu je nejpraktičtějším přístupem použití klientské implementace [Erigon](/developers/docs/nodes-and-clients/#erigon). + +### Hardware + +Vždy si ověřte hardwarové požadavky pro daný režim v dokumentaci klienta. +Největším požadavkem pro archivní uzly je místo na disku. V závislosti na klientovi se pohybuje od 3 TB do 12 TB. I když by se pro velké objemy dat mohl disk HDD považovat za lepší řešení, jeho synchronizace a neustálá aktualizace špičky řetězce budou vyžadovat disky SSD. Disky [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) jsou dostatečně dobré, ale měly by být spolehlivé kvality, alespoň [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). Disky lze umístit do stolního počítače nebo serveru s dostatečným počtem slotů. Tato vyhrazená zařízení jsou ideální pro provoz uzlu s vysokou dostupností. Je zcela možné jej provozovat na notebooku, ale přenosnost bude spojena s dalšími náklady. + +Všechna data se musí vejít na jeden svazek, proto je třeba disky spojit, např. pomocí [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) nebo LVM. Za zvážení může stát také použití systému [ZFS](https://en.wikipedia.org/wiki/ZFS), protože podporuje funkci "Copy-on-write", která zajišťuje správný zápis dat na disk bez jakýchkoli nízkoúrovňových chyb. + +Pro větší stabilitu a zabezpečení při prevenci náhodného poškození databáze, zejména v profesionálním prostředí, zvažte použití [paměti ECC](https://en.wikipedia.org/wiki/ECC_memory), pokud ji váš systém podporuje. Obecně se doporučuje, aby velikost paměti RAM byla stejná jako pro plný uzel, ale více paměti RAM může pomoci urychlit synchronizaci. + +Během počáteční synchronizace provedou klienti v archivním režimu všechny transakce od geneze. Rychlost provádění je většinou omezena procesorem, takže rychlejší procesor může pomoci zkrátit dobu počáteční synchronizace. Na průměrném spotřebitelském počítači může počáteční synchronizace trvat až měsíc. + +## Další čtení {#further-reading} + +- [Plný uzel Etherea vs. archivní uzel](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) – _QuickNode, září 2022_ +- [Vytvoření vlastního archivního uzlu Etherea](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) – _Thomas Jay Rush, srpen 2021_ +- [Jak nastavit Erigon, Erigon RPC a TrueBlocks (scrape a API) jako služby](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) _– Magnus Hansson, aktualizováno v září 2022_ + +## Související témata {#related-topics} + +- [Uzly a klienti](/developers/docs/nodes-and-clients/) +- [Provozování uzlu](/developers/docs/nodes-and-clients/run-a-node/) diff --git a/public/content/translations/cs/developers/docs/nodes-and-clients/bootnodes/index.md b/public/content/translations/cs/developers/docs/nodes-and-clients/bootnodes/index.md new file mode 100644 index 00000000000..9a933dd3818 --- /dev/null +++ b/public/content/translations/cs/developers/docs/nodes-and-clients/bootnodes/index.md @@ -0,0 +1,31 @@ +--- +title: "Úvod do Ethereum bootnodů" +description: "Základní informace, které potřebujete k pochopení bootnodů" +lang: cs +--- + +Když se nový uzel připojí k síti Ethereum, musí se spojit s uzly, které již v síti jsou, aby mohl objevit další peery. Těmto vstupním bodům do sítě Ethereum se říká bootnody. Klienti v sobě mají obvykle pevně zakódovaný seznam bootnodů. Tyto bootnody jsou obvykle provozovány devops týmem nadace Ethereum nebo samotnými týmy klientů. Všimněte si, že bootnody nejsou totéž co statické uzly. Statické uzly jsou volány stále dokola, zatímco bootnody jsou volány pouze v případě, že není dostatek peerů pro připojení a uzel potřebuje navázat některá nová spojení. + +## Připojení k bootnodu {#connect-to-a-bootnode} + +Většina klientů má v sobě zabudovaný seznam bootnodů, ale možná budete chtít provozovat vlastní bootnode nebo použít takový, který není součástí pevně zakódovaného seznamu klienta. V takovém případě je můžete určit při spouštění vašeho klienta následujícím způsobem (příklad je pro Geth, podívejte se prosím do dokumentace vašeho klienta): + +``` +geth --bootnodes "enode://@:" +``` + +## Provozování bootnodu {#run-a-bootnode} + +Bootnody jsou plnohodnotné uzly, které nejsou za NAT ([překlad síťových adres](https://www.geeksforgeeks.org/network-address-translation-nat/)). Každý plnohodnotný uzel může fungovat jako bootnode, pokud je veřejně dostupný. + +Když spustíte uzel, měl by se vám zobrazit váš [enode](/developers/docs/networking-layer/network-addresses/#enode), což je veřejný identifikátor, který mohou ostatní použít k připojení k vašemu uzlu. + +Enode se obvykle regeneruje při každém restartu, takže se podívejte do dokumentace vašeho klienta, jak vygenerovat trvalý enode pro váš bootnode. + +Abyste byli dobrým bootnodem, je dobré navýšit maximální počet peerů, kteří se k němu mohou připojit. Provozování bootnodu s mnoha peery výrazně zvýší nároky na šířku pásma. + +## Dostupné bootnody {#available-bootnodes} + +Seznam vestavěných bootnodů v go-ethereum naleznete [zde](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Tyto bootnody jsou spravovány nadací Ethereum a týmem go-ethereum. + +K dispozici jsou i další seznamy bootnodů spravované dobrovolníky. Ujistěte se prosím, že vždy zahrnete alespoň jeden oficiální bootnode, jinak byste se mohli stát obětí eclipse útoku.