Merge branch 'dev' into irish

Author: wackerow

public/content/contributing/translation-program/translators-guide/index.md

@@ -122,7 +122,7 @@ The best way to handle links is to copy them directly from the source, either by
 
 ![Example of link.png](./example-of-link.png)
 
-Links also appear in the source text in the form of tags (i.e. \<0> \</0>). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links.
+Links also appear in the source text in the form of tags (i.e. `<0>` `</0>`). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links.
 
 It is very important to copy the links from the source and not change their order.
 
@@ -160,7 +160,7 @@ nonce - _Non-translatable text_
 
 The source text also contains shortened tags, which only contain numbers, meaning that their function is not immediately obvious. You can hover over these tags to see exactly which function they serve.
 
-In the example below, you can see that hovering over the \<0> tag shows that it represents `<code>` and contains a code snippet, therefore the content inside these tags should not be translated.
+In the example below, you can see that hovering over the `<0>` tag shows that it represents `<code>` and contains a code snippet, therefore the content inside these tags should not be translated.
 
 ![Example of ambiguous tags.png](./example-of-ambiguous-tags.png)
 

public/content/developers/docs/smart-contracts/formal-verification/index.md

@@ -70,7 +70,7 @@ Low-level formal specifications can be given as either Hoare-style properties or
 
 ### Hoare-style properties {#hoare-style-properties}
 
-[Hoare Logic](https://en.wikipedia.org/wiki/Hoare_logic) provides a set of formal rules for reasoning about the correctness of programs, including smart contracts. A Hoare-style property is represented by a Hoare triple \{_P_}_c_\{_Q_}, where _c_ is a program and _P_ and _Q_ are predicates on the state of the _c_ (i.e., the program), formally described as _preconditions_ and _postconditions_, respectively.
+[Hoare Logic](https://en.wikipedia.org/wiki/Hoare_logic) provides a set of formal rules for reasoning about the correctness of programs, including smart contracts. A Hoare-style property is represented by a Hoare triple `{P}c{Q}`, where `c` is a program and `P` and `Q` are predicates on the state of the `c` (i.e., the program), formally described as _preconditions_ and _postconditions_, respectively.
 
 A precondition is a predicate describing the conditions required for the correct execution of a function; users calling into the contract must satisfy this requirement. A postcondition is a predicate describing the condition that a function establishes if correctly executed; users can expect this condition to be true after calling into the function. An _invariant_ in Hoare logic is a predicate that is preserved by execution of a function (i.e., it doesn't change).
 

public/content/roadmap/account-abstraction/index.md

@@ -10,9 +10,9 @@ summaryPoints:
 
 # Account abstraction {#account-abstraction}
 
-Users interact with Ethereum using **[externally owned accounts (EOAs)](/glossary/#eoa)**. This is the only way to start a transaction or execute a smart contract. This limits how users can interact with Ethereum. For example, it makes it difficult to do batches of transactions and requires users to always keep an ETH balance to cover gas.
+Most existing users interact with Ethereum using **[externally owned accounts (EOAs)](/glossary/#eoa)**. This limits how users can interact with Ethereum. For example, it makes it difficult to do batches of transactions and requires users to always keep an ETH balance to pay transaction fees. 
 
-Account abstraction is a way to solve these problems by allowing users to flexibly program more security and better user experiences into their accounts. This can happen by [upgrading EOAs](https://eips.ethereum.org/EIPS/eip-3074) so they can be controlled by smart contracts, or by [upgrading smart contracts](https://eips.ethereum.org/EIPS/eip-2938) so they can initiate transactions. These options both require changes to the Ethereum protocol. There is also a third path involving adding a [second, separate transaction system](https://eips.ethereum.org/EIPS/eip-4337) to run in parallel to the existing protocol. Regardless of the route, the outcome is access to Ethereum via smart contract wallets, either natively supported as part of the existing protocol or via an add-on transaction network.
+Account abstraction is a way to solve these problems by allowing users to flexibly program more security and better user experiences into their accounts. This can happen by [upgrading EOAs](https://eips.ethereum.org/EIPS/eip-7702) so they can be controlled by smart contracts. There is also another path involving adding a [second, separate transaction system](https://eips.ethereum.org/EIPS/eip-4337) to run in parallel to the existing protocol. Regardless of the route, the outcome is access to Ethereum via smart contract wallets, either natively supported as part of the existing protocol or via an add-on transaction network.
 
 Smart contract wallets unlock many benefits for the user, including:
 
@@ -74,12 +74,6 @@ These are just a few examples of how user experiences could be leveled up by acc
 
 Smart contract wallets exist today but are challenging to implement because the EVM does not support them. Instead, they rely on wrapping relatively complex code around standard Ethereum transactions. Ethereum can change this by allowing smart contracts to initiate transactions, handling the necessary logic in Ethereum smart contracts instead of offchain. Putting logic into smart contracts also increases Ethereum's decentralization since it removes the need for "relayers" run by wallet developers to translate messages signed by the user to regular Ethereum transactions.
 
-<ExpandableCard title="EIP-2771: account abstraction using meta-transactions" eventCategory="/roadmap/account-abstract" eventName="clicked EIP-2771: account abstraction using meta-transactions">
-
-EIP-2771 introduces the concept of meta-transactions that allow third parties to pay for a user's gas costs without making changes to the Ethereum protocol. The idea is that transactions signed by a user get sent to a `Forwarder` contract. The forwarder is a trusted entity that verifies that transactions are valid before sending them on to a gas relay. This is done offchain, avoiding the need to pay gas. The gas relay passes the transaction on to a `Recipient` contract, paying the necessary gas to make the transaction executable on Ethereum. The transaction is executed if the `Forwarder` is known and trusted by the `Recipient`. This model makes it easy for developers to implement gasless transactions for users.
-
-</ExpandableCard>
-
 <ExpandableCard title="EIP-4337: account abstraction without changing the Ethereum protocol" eventCategory="/roadmap/account-abstract" eventName="clicked EIP-4337: account abstraction without changing the Ethereum protocol">
 
 EIP-4337 is the first step towards native smart contract wallet support in a decentralized way <em>without requiring changes to the Ethereum protocol</em>. Instead of modifying the consensus layer to support smart contract wallets, a new system is added separately to the normal transaction gossip protocol. This higher-level system is built around a new object called a <code>UserOperation</code> that package up actions from a user along with the relevant signatures. These <code>UserOperation</code> objects then get broadcast into a dedicated mempool where validators can collect them into a "bundle transaction". The bundle transaction represents a sequence of many individual <code>UserOperations</code> and can be included in Ethereum blocks just like a normal transaction, and would be picked up by validators using a similar fee-maximizing selection model.
@@ -90,25 +84,9 @@ The way wallets work would also change under EIP-4337. Instead of each wallet re
 
 </ExpandableCard>
 
-<ExpandableCard title="EIP-2938: changing the Ethereum protocol to support account abstraction" eventCategory="/roadmap/account-abstract" eventName="clicked EIP-2938: changing the Ethereum protocol to support account abstraction">
-
-<a href="https://eips.ethereum.org/EIPS/eip-2938">EIP-2938</a> aims to update the Ethereum protocol by introducing a new transaction type, <code>AA_TX_TYPE</code> that includes three fields: <code>nonce</code>, <code>target</code> and <code>data</code>, where <code>nonce</code> is a transaction counter, <code>target</code> is the entry point contract address and <code>data</code> is EVM bytecode. To execute these transactions, two new instructions (known as opcodes) have to be added to the EVM: <code>NONCE</code> and <code>PAYGAS</code>. The <code>NONCE</code> opcode tracks the transaction sequence and <code>PAYGAS</code> calculates and withdraws the gas required to execute the transaction from the contract&#39;s balance. These new features allow Ethereum to support smart contract wallets natively as the necessary infrastructure is built into Ethereum&#39;s protocol.
-
-Note that EIP-2938 is currently not active. The community is currently favoring EIP-4337 because it does not require changes to the protocol.
-
-</ExpandableCard>
-
-<ExpandableCard title="EIP-3074: upgrading externally-owned accounts for account abstraction" eventCategory="/roadmap/account-abstract" eventName="clicked EIP-3074: upgrading externally-owned accounts for account abstraction">
-
-<a href="https://eips.ethereum.org/EIPS/eip-3074">EIP-3074</a> aims to update Ethereum&#39;s externally-owned accounts by allowing them to delegate control to a smart contract. This means smart contract logic could approve transactions originating from an EOA. This would allow features such as gas-sponsoring and batched transactions. For this to work, two new opcodes have to be added to the EVM: <code>AUTH</code> and <code>AUTHCALL</code>. With EIP-3074 the benefits of a smart contract wallet are made available <em>without needing a contract</em> - instead, a specific type of stateless, trustless, non-upgradeable contract known as an "invoker" handles the transactions.
-
-Note that EIP-3074 is currently not active. The community is currently favoring EIP-4337 because it does not require changes to the protocol.
-
-</ExpandableCard>
-
 ## Current progress {#current-progress}
 
-Smart contract wallets are already available, but more upgrades are required to make them as decentralized and permissionless as possible. EIP-4337 is a mature proposal that does not require any changes to Ethereum's protocol, so it is possible that this could be implemented quickly. However, upgrades that alter Ethereum's protocol are currently not in active development, so those changes may take much longer to ship. It is also possible that account abstraction is achieved well enough by EIP-4337 that no protocol changes are ever required. 
+**The next two Ethereum upgrades ([Pectra](/roadmap/pectra/) and later Fusaka) will address these improvements.** Pectra will be released soon in upcomming months. Smart contract wallets are already available. EIP-4337 is a mature proposal that does not require any changes to Ethereum's protocol, so many wallets have started adopting this standard.
 
 **Note**: You can track adoption of ERC-4337 smart contract wallets [via this dashboard](https://www.bundlebear.com/overview/all).
 
@@ -120,11 +98,8 @@ Smart contract wallets are already available, but more upgrades are required to
 - ["Account abstraction ELI5" from Devcon Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY)
 - [Vitalik's "Road to Account Abstraction" notes](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists)
 - [Vitalik's blog post on social recovery wallets](https://vitalik.eth.limo/general/2021/01/11/recovery.html)
-- [EIP-2938 notes](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938)
-- [EIP-2938 documentation](https://eips.ethereum.org/EIPS/eip-2938)
 - [EIP-4337 notes](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a)
 - [EIP-4337 documentation](https://eips.ethereum.org/EIPS/eip-4337)
-- [EIP-2771 documentation](https://eips.ethereum.org/EIPS/eip-2771)
 - ["Basics of Account Abstraction" -- What is Account Abstraction Part I](https://www.alchemy.com/blog/account-abstraction)
 - [Charting Ethereum's Account Abstraction Roadmap I: EIP-3074, EIP-5806, & EIP-7702](https://research.2077.xyz/charting-ethereums-account-abstraction-roadmap-eip-3074-eip-5806-eip-7702)
 - [Awesome Account Abstraction](https://github.com/4337Mafia/awesome-account-abstraction)

public/content/translations/cs/community/get-involved/index.md

@@ -59,12 +59,12 @@ Pokud nejste vývojář, může být obtížné zjistit, jak začít pracovat s
 
 ### Nabídněte pomoc při psaní poznámek během komunitních hovorů {#take-notes}
 
-- Existuje mnoho hovorů open-source komunit a mít osobu dedikovanou na zápis poznámek je velká pomoc. Pokud máte zájem, připojte se k [Discordu Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) a představte se!
+- Existuje mnoho hovorů open-source komunit a mít osobu dedikovanou na zápis poznámek je velká pomoc. Pokud máte zájem, připojte se k [Discordu Ethereum Cat Herders ](https://discord.com/invite/Nz6rtfJ8Cu)a představte se!
 
 ### Překládejte obsah o Ethereu do svého rodného jazyka {#translate-ethereum}
 
 - ethereum.org má program věnovaný překladům, který překládá webové stránky a další zdroje do mnoha různých jazyků
-- [Tady](/contributing/translation-program) zjistíte, jak se můžete zapojit
+- [Tady ](/contributing/translation-program)zjistíte, jak se můžete zapojit
 
 ### Spustit uzel {#run-a-node}
 

public/content/translations/cs/contributing/translation-program/translators-guide/index.md

@@ -116,7 +116,7 @@ Nejlepší způsob, jak pracovat s odkazy, je kopírovat je přímo ze zdroje, b
 
 ![Příklad odkazu.png](./example-of-link.png)
 
-Odkazy se také zobrazují ve zdrojovém textu ve formě tagů (tj. \<0> \</0>). Pokud na tag umístíte kurzor, editor zobrazí jeho celý obsah – někdy tyto tagy představují odkazy.
+Odkazy se také zobrazují ve zdrojovém textu ve formě tagů (tj. `<0>` `</0>`). Pokud na tag umístíte kurzor, editor zobrazí jeho celý obsah – někdy tyto tagy představují odkazy.
 
 Je velmi důležité zkopírovat odkazy ze zdroje a neměnit jejich pořadí.
 
@@ -154,7 +154,7 @@ nonce – _text, který není určen k překladu_
 
 Zdrojový text také obsahuje zkrácené tagy, které obsahují pouze čísla, což znamená, že jejich funkce není okamžitě zřejmá. Můžete na tyto tagy najet kurzorem, abyste přesně zjistili, jakou funkci plní.
 
-V příkladu níže můžete vidět, že když najedete kurzorem na tag \<0> , zobrazí se, že představuje `<code>` a obsahuje úryvek kódu, takže obsah uvnitř těchto tagů by neměl být přeložen.
+V příkladu níže můžete vidět, že když najedete kurzorem na tag `<0>` , zobrazí se, že představuje `<code>` a obsahuje úryvek kódu, takže obsah uvnitř těchto tagů by neměl být přeložen.
 
 ![Příklad nejednoznačných tagů.png](./example-of-ambiguous-tags.png)
 

public/content/translations/cs/desci/index.md

@@ -126,7 +126,7 @@ Uvítáme návrhy na nové projekty, které je třeba uvést na seznam – pro z
 - [DeSci: Budoucnost výzkumu od Samuela Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec)
 - [Financování vědy (Epilolog: DeSci a nové krypto základní prvky) od Nadie](https://nadia.xyz/science-funding)
 - [Decentralizace narušuje vývoj léků](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f)
-- [Co je DeSci – decentralizovaná věda?](​https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
+- [Co je DeSci – decentralizovaná věda?](https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/)
 
 ### Videa {#videos}
 

public/content/translations/cs/developers/docs/intro-to-ether/index.md

@@ -22,7 +22,7 @@ První kryptoměnou byl Bitcoin, který vytvořil Satoshi Nakamoto. Od spuštěn
 
 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.
 
-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 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.
 
 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.
 
@@ -73,6 +73,6 @@ Uživatelé mohou zjistit zůstatek etheru na jakémkoliv [účtu](/developers/d
 
 - [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 ethereum. Stačí zadat jakoukoliv částku ve wei, gwei nebo ETH a automaticky vypočítat konverzi.
+- [Kalkulačka gwei](https://www.alchemy.com/gwei-calculator): Použijte tuto kalkulačku gwei pro snadnou konverzi 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!_

public/content/translations/cs/developers/docs/smart-contracts/formal-verification/index.md

@@ -70,9 +70,7 @@ Formální specifikace na nízké úrovni mohou být uvedeny buď jako vlastnost
 
 ### Vlastnosti ve stylu Hoareovy logiky {#hoare-style-properties}
 
-[Hoareova logika](https://en.wikipedia.org/wiki/Hoare_logic) poskytuje sadu formálních pravidel pro uvažování o správnosti programů, včetně chytrých kontraktů. Vlastnost ve stylu Hoareovy logiky je reprezentována jako Hoareův trojúhelník \{_P_}_c_\{_Q_}, kde _c_ je program a _P_ a _Q_ jsou predikáty na stavu _c_ (tj. programu), formálně popsané jako _předpoklady_ a _podmínky následku_.
-
-Předpoklad je predikát popisující podmínky potřebné pro správné provedení funkce; uživatelé volající kontrakt musí tuto podmínku splnit. Podmínka následku je predikát popisující podmínku, kterou funkce stanoví, pokud je správně provedena; uživatelé mohou očekávat, že tato podmínka bude po volání funkce pravdivá. _Invariant_ v Hoareově logice je predikát, který je zachován při provádění funkce (tj. nemění se).
+[Hoareova logika](https://en.wikipedia.org/wiki/Hoare_logic) poskytuje sadu formálních pravidel pro uvažování o správnosti programů, včetně chytrých kontraktů. Vlastnost ve stylu Hoareovy logiky je reprezentována jako Hoareův trojúhelník `{P}c{Q}`, kde `c` je program a `P` a `Q` jsou predikáty na stavu `c` (tj. programu), formálně popsané jako _předpoklady_ a _podmínky následku_.
 
 Specifikace ve stylu Hoareovy logiky mohou zaručit buď _částečnou správnost_, _nebo úplnou správnost_. Implementace funkce kontraktu je „částečně správná“, pokud předpoklad platí před provedením funkce a když provedení končí, podmínka následku je také pravdivá. Důkaz úplné správnosti je obdržen, pokud je předpoklad pravdivý před provedením funkce, dále je zaručeno, že provádění funkce bude ukončeno, a když k tomu dojde, následek bude pravdivý.