ethereum · wackerow · Mar 2, 2026 · Feb 26, 2026 · Feb 26, 2026 · Feb 26, 2026
@@ -114,6 +114,7 @@ export default async function Page({ params }: { params: Promise<Params> }) {
   const { locale } = await params
 
   const t = await getTranslations({ namespace: "page-bug-bounty" })
+  const tCommon = await getTranslations({ namespace: "common" })
 
   const commitHistoryCache: CommitHistory = {}
   const { contributors, lastEditLocaleTimestamp } =
@@ -305,39 +306,83 @@ export default async function Page({ params }: { params: Promise<Params> }) {
         </Text>
         <ClientRow>
           <Client>
-            <Image src={besu} alt="" {...iconImageProps()} />
+            <Image
+              src={besu}
+              alt={tCommon("item-logo", { item: "Besu" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={erigon} alt="" {...iconImageProps()} />
+            <Image
+              src={erigon}
+              alt={tCommon("item-logo", { item: "Erigon" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={geth} alt="" {...iconImageProps()} />
+            <Image
+              src={geth}
+              alt={tCommon("item-logo", { item: "Geth" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={nethermind} alt="" {...iconImageProps()} />
+            <Image
+              src={nethermind}
+              alt={tCommon("item-logo", { item: "Nethermind" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={reth} alt="" {...iconImageProps()} />
+            <Image
+              src={reth}
+              alt={tCommon("item-logo", { item: "Reth" })}
+              {...iconImageProps()}
+            />
           </Client>
         </ClientRow>
         <ClientRow>
           <Client>
-            <Image src={lighthouseLight} alt="" {...iconImageProps(true)} />
+            <Image
+              src={lighthouseLight}
+              alt={tCommon("item-logo", { item: "Lighthouse" })}
+              {...iconImageProps(true)}
+            />
           </Client>
           <Client>
-            <Image src={lodestar} alt="" {...iconImageProps()} />
+            <Image
+              src={lodestar}
+              alt={tCommon("item-logo", { item: "Lodestar" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={nimbus} alt="" {...iconImageProps()} />
+            <Image
+              src={nimbus}
+              alt={tCommon("item-logo", { item: "Nimbus" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={prysm} alt="" {...iconImageProps()} />
+            <Image
+              src={prysm}
+              alt={tCommon("item-logo", { item: "Prysm" })}
+              {...iconImageProps()}
+            />
           </Client>
           <Client>
-            <Image src={tekuLight} alt="" {...iconImageProps(true)} />
+            <Image
+              src={tekuLight}
+              alt={tCommon("item-logo", { item: "Teku" })}
+              {...iconImageProps(true)}
+            />
           </Client>
           <Client>
-            <Image src={grandine} alt="" {...iconImageProps()} />
+            <Image
+              src={grandine}
+              alt={tCommon("item-logo", { item: "Grandine" })}
+              {...iconImageProps()}
+            />
           </Client>
         </ClientRow>
         <div className="mb-12 mt-8 w-full border-t bg-background-highlight px-0 py-16 shadow-table-item-box">

@@ -146,8 +146,8 @@ A summary of the control flow is shown below, with the relevant networking stack
 
 Once the block has been attested by sufficient validators it is added to the head of the chain, justified and eventually finalized.
 
-![](cons_client_net_layer.png)
-![](exe_client_net_layer.png)
+![Diagram of the Ethereum consensus client networking layer](cons_client_net_layer.png)
+![Diagram of the Ethereum execution client networking layer](exe_client_net_layer.png)
 
 Network layer schematic for consensus and execution clients, from [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248)
 

@@ -10,7 +10,7 @@ When Ethereum was using [proof-of-work](/developers/docs/consensus-mechanisms/po
 
 The diagram below shows the relationship between the two Ethereum clients. The two clients connect to their own respective peer-to-peer (P2P) networks. Separate P2P networks are needed as the execution clients gossip transactions over their P2P network, enabling them to manage their local transaction pool, whilst the consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.
 
-![](node-architecture-text-background.png)
+![Diagram of Ethereum node architecture showing execution and consensus layers](node-architecture-text-background.png)
 
 _There are several options for the execution client including Erigon, Nethermind, and Besu_.
 

@@ -241,7 +241,7 @@ Do not name it `process.env` or `.env-custom` or anything else.
 - Follow [these instructions](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) to export your private key
 - See below to get HTTP Alchemy API URL
 
-![](./get-alchemy-api-key.gif)
+![Animated walkthrough of getting an Alchemy API key](./get-alchemy-api-key.gif)
 
 Your `.env` should look like this:
 

@@ -62,13 +62,13 @@ This will yield the same information as provided on Etherscan's transaction page
 
 #### Etherscan {#etherscan}
 
-![](./etherscan_view.png)
+![Screenshot of Etherscan transaction explorer view](./etherscan_view.png)
 
 [EF's contract page on Blockscout.](https://eth.blockscout.com/address/0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe)
 
 #### Dune Analytics {#dune-analytics}
 
-![](./dune_view.png)
+![Screenshot of a Dune Analytics query dashboard](./dune_view.png)
 
 You can find dashboard [here](https://dune.com/paulapivat/Learn-Ethereum). Click on the table to see the query (also see above).
 
@@ -146,7 +146,7 @@ ORDER BY block_time DESC`
 
 Here's the SQL output on Dune:
 
-![](./list_of_txn.png)
+![Screenshot of a list of Ethereum transactions](./list_of_txn.png)
 
 This single block being added to the chain changes the state of the Ethereum virtual machine ([EVM](/developers/docs/evm/)). Dozens sometimes, hundreds of transactions are verified at once. In this specific case, 222 transactions were included.
 
@@ -165,19 +165,19 @@ FROM temp_table
 
 For block 12396854, out of 222 total transactions, 204 were successfully verified:
 
-![](./successful_txn.png)
+![Screenshot of a successful Ethereum transaction](./successful_txn.png)
 
 Transactions requests occur dozens of times per second, but blocks are committed approximately once every 15 seconds ([source](/developers/docs/blocks/)).
 
 To see that there is one block produced approximately every 15 seconds, we could take the number of seconds in a day (86400) divided by 15 to get an estimated average number of blocks per day (~ 5760).
 
 The chart for Ethereum blocks produced per day (2016 - present) is:
 
-![](./daily_blocks.png)
+![Chart showing daily Ethereum block production](./daily_blocks.png)
 
 The average number of blocks produced daily over this time period is ~5,874:
 
-![](./avg_daily_blocks.png)
+![Chart showing daily Ethereum block production](./avg_daily_blocks.png)
 
 The queries are:
 
@@ -214,7 +214,7 @@ Blocks are bounded in size. The maximum block size is dynamic and varies accordi
 
 One way to conceptualize block gas limit is to think of it as the **supply** of available block space in which to batch transactions. The block gas limit can be queried and visualized from 2016 to present day:
 
-![](./avg_gas_limit.png)
+![Chart showing average Ethereum gas limit over time](./avg_gas_limit.png)
 
 ```sql
 SELECT
@@ -227,7 +227,7 @@ OFFSET 1
 
 Then there is the actual gas used daily to pay for computing done on the Ethereum chain (i.e., sending transaction, calling a smart contract, minting an NFT). This is the **demand** for available Ethereum block space:
 
-![](./daily_gas_used.png)
+![Chart showing daily Ethereum gas used](./daily_gas_used.png)
 
 ```sql
 SELECT
@@ -246,7 +246,7 @@ Therefore we can understand gas prices as a function of demand for Ethereum bloc
 
 Finally, we may want to query average daily gas prices for the Ethereum chain, however, doing so will result in an especially long query time, so we’ll filter our query to the average amount of gas paid per transaction by the Ethereum Foundation.
 
-![](./ef_daily_gas.png)
+![Chart showing Ethereum Foundation daily gas usage](./ef_daily_gas.png)
 
 We can see gas prices paid for all transactions made to the Ethereum Foundation address over the years. Here is the query:
 

@@ -117,35 +117,35 @@ sudo systemctl start grafana-server
 When you've got Grafana running, it should be reachable at `localhost:3000`.
 Use your preferred browser to access this path, then login with the default credentials (user: `admin` and password: `admin`). When prompted, change the default password and save.
 
-![](./grafana1.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 1)](./grafana1.png)
 
 You will be redirected to the Grafana home page. First, set up your source data. Click on the configuration icon in the left bar and select "Data sources".
 
-![](./grafana2.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 2)](./grafana2.png)
 
 There aren't any data sources created yet, click on "Add data source" to define one.
 
-![](./grafana3.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 3)](./grafana3.png)
 
 For this setup, select "InfluxDB" and proceed.
 
-![](./grafana4.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 4)](./grafana4.png)
 
 Data source configuration is pretty straight forward if you are running tools on the same machine. You need to set the InfluxDB address and details for accessing the database. Refer to the picture below.
 
-![](./grafana5.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 5)](./grafana5.png)
 
 If everything is complete and InfluxDB is reachable, click on "Save and test" and wait for the confirmation to pop up.
 
-![](./grafana6.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 6)](./grafana6.png)
 
 Grafana is now set up to read data from InfluxDB. Now you need to create a dashboard which will interpret and display it. Dashboards properties are encoded in JSON files which can be created by anybody and easily imported. On the left bar, click on "Create and Import".
 
-![](./grafana7.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 7)](./grafana7.png)
 
 For a Geth monitoring dashboard, copy the ID of [this dashboard](https://grafana.com/grafana/dashboards/13877/) and paste it in the "Import page" in Grafana. After saving the dashboard, it should look like this:
 
-![](./grafana8.png)
+![Grafana dashboard screenshot for Geth monitoring (panel 8)](./grafana8.png)
 
 You can modify your dashboards. Each panel can be edited, moved, removed or added. You can change your configurations. It's up to you! To learn more about how dashboards work, refer to [Grafana's documentation](https://grafana.com/docs/grafana/latest/dashboards/).
 You might also be interested in [Alerting](https://grafana.com/docs/grafana/latest/alerting/). This lets you set up alert notifications for when metrics reach certain values. Various communication channels are supported.
@@ -83,7 +83,7 @@ First let's talk about GraphQL, originally designed and implemented by Facebook.
 
 ![GraphQL API vs. REST API](./graphql.jpg)
 
-![](./graphql-query.gif)
+![Animated demonstration of a GraphQL query in The Graph playground](./graphql-query.gif)
 
 The two images pretty much capture the essence of GraphQL. With the query on the right we can define exactly what data we want, so there we get everything in one request and nothing more than exactly what we need. A GraphQL server handles the fetching of all data required, so it is incredibly easy for the frontend consumer side to use. [This is a nice explanation](https://www.apollographql.com/blog/graphql-explained) of how exactly the server handles a query if you're interested.
 

@@ -41,7 +41,7 @@ The witness size varies depending on the number of leaves it includes. Assuming
 
 Verkle trees are `(key,value)` pairs where the keys are 32-byte elements composed of a 31-byte _stem_ and a single byte _suffix_. These keys are organized into _extension_ nodes and _inner_ nodes. Extension nodes represent a single stem for 256 children with different suffixes. Inner nodes also have 256 children, but they can be other extension nodes. The main difference between the Verkle tree and the Merkle tree structure is that the Verkle tree is much flatter, meaning there are fewer intermediate nodes linking a leaf to the root, and therefore less data required to generate a proof.
 
-![](./verkle.png)
+![Diagram of a Verkle tree data structure](./verkle.png)
 
 [Read more about the structure of Verkle trees](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)
 

@@ -146,8 +146,8 @@ SSZ মানে হল সিম্পল সিরিয়ালাইজেশ
 
 একবার ব্লকটি পর্যাপ্ত ভ্যালিডেটর দ্বারা অ্যাটেস্টেড হয়ে গেলে এটি চেইনের শীর্ষে যুক্ত হয়, ন্যায্য বলে বিবেচিত হয় এবং অবশেষে চূড়ান্ত হয়।
 
-![](cons_client_net_layer.png)
-![](exe_client_net_layer.png)
+![Ethereum ঐক্যমত ক্লায়েন্ট নেটওয়ার্কিং স্তরের চিত্র](cons_client_net_layer.png)
+![ইথেরিয়াম এক্সিকিউশন ক্লায়েন্ট নেটওয়ার্কিং স্তরের চিত্র](exe_client_net_layer.png)
 
 [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) থেকে কনসেন্সাস এবং এক্সিকিউশন ক্লায়েন্টদের জন্য নেটওয়ার্ক লেয়ার স্কিম্যাটিক
 

@@ -10,7 +10,7 @@ lang: bn
 
 নীচের ডায়াগ্রামটি দুটি ইথেরিয়াম ক্লায়েন্টের মধ্যে সম্পর্ক দেখায়। দুটি ক্লায়েন্ট তাদের নিজ নিজ পিয়ার-টু-পিয়ার (P2P) নেটওয়ার্কের সাথে সংযুক্ত হয়। আলাদা P2P নেটওয়ার্কের প্রয়োজন হয়, কারণ এক্সিকিউশন ক্লায়েন্টরা তাদের P2P নেটওয়ার্কের মাধ্যমে লেনদেন গসিপ করে, যা তাদের স্থানীয় লেনদেন পুল পরিচালনা করতে সক্ষম করে, অন্যদিকে কনসেন্সাস ক্লায়েন্টরা তাদের P2P নেটওয়ার্কের মাধ্যমে ব্লক গসিপ করে, যা কনসেন্সাস এবং চেইন বৃদ্ধি সক্ষম করে।
 
-![](node-architecture-text-background.png)
+![Ethereum নোড আর্কিটেকচারের ডায়াগ্রাম এক্সিকিউশন এবং কনসেনসাস লেয়ার দেখাচ্ছে](node-architecture-text-background.png)
 
 _এক্সিকিউশন ক্লায়েন্টের জন্য Erigon, Nethermind, এবং Besu সহ বেশ কয়েকটি বিকল্প রয়েছে।_
 

@@ -146,7 +146,7 @@ Souhrn toku řízení je uveden níže, s relevantní síťovou vrstvou v závor
 
 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 klienta Ethereum consensus](cons_client_net_layer.png)\n![Schéma síťové vrstvy klienta pro provádění Etherea](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)
 

@@ -10,7 +10,7 @@ Když Ethereum používalo [důkaz prací](/developers/docs/consensus-mechanisms
 
 Níže uvedený diagram znázorňuje vztah mezi dvěma klienty sítě Ethereum. Oba klienti se připojují ke svým vlastním sítím peer-to-peer (P2P). Jsou zapotřebí oddělené P2P sítě, protože exekuční klienti si přes svou P2P síť vyměňují transakce, což jim umožňuje spravovat jejich lokální transakční pool, zatímco konsensuální klienti si přes svou P2P síť vyměňují bloky, což umožňuje konsensus a růst řetězce.
 
-![](node-architecture-text-background.png)
+![Diagram architektury uzlu Ethereum zobrazující prováděcí a konsensuální vrstvy](node-architecture-text-background.png)
 
 _Pro exekučního klienta existuje několik možností, včetně Erigon, Nethermind a Besu_.
 

@@ -240,7 +240,7 @@ Nenazývejte jej `process.env` ani `.env-custom` ani nijak jinak.
 - Postupujte podle [těchto pokynů](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) a exportujte svůj privátní klíč
 - Níže naleznete postup, jak získat URL pro HTTP API Alchemy
 
-![](./get-alchemy-api-key.gif)
+![Animovaný návod, jak získat klíč Alchemy API](./get-alchemy-api-key.gif)
 
 Váš soubor `.env` by měl vypadat takto:
 
@@ -359,17 +359,17 @@ Kontrakt nasazen na adresu: 0x6cd7d44516a20882cEa2DE9f205bF401c0d23570
 
 Pokud přejdeme na [Goerli Etherscan](https://goerli.etherscan.io) a vyhledáme adresu našeho kontraktu, měli bychom vidět, že byl úspěšně nasazen. Transakce bude vypadat nějak takto:
 
-![](./etherscan-contract.png)
+![Snímek obrazovky nasazené chytré smlouvy na Etherscan](./etherscan-contract.png)
 
 Adresa `From` by se měla shodovat s adresou vašeho účtu MetaMask a v adrese `To` bude uvedeno **Vytvoření kontraktu**. Pokud klikneme na transakci, uvidíme v poli `To` adresu našeho kontraktu.
 
-![](./etherscan-transaction.png)
+![Snímek obrazovky transakce na Etherscan](./etherscan-transaction.png)
 
 Výborně! Právě jste nasadili chytrý kontrakt do testovací sítě Ethereum.
 
 Abyste pochopili, co se děje pod pokličkou, přejděte na kartu Průzkumník v našem [řídicím panelu Alchemy](https://dashboard.alchemy.com/explorer). Pokud máte více aplikací Alchemy, nezapomeňte filtrovat podle aplikace a vybrat **Hello World**.
 
-![](./hello-world-explorer.png)
+![Snímek obrazovky chytré smlouvy Hello World v průzkumníku bloků](./hello-world-explorer.png)
 
 Zde uvidíte několik metod JSON-RPC, které pro nás Hardhat/Ethers vytvořil pod pokličkou, když jsme volali funkci `.deploy()`. Dvě důležité metody jsou zde [`eth_sendRawTransaction`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_sendrawtransaction), což je požadavek na zapsání našeho kontraktu do chainu Goerli, a [`eth_getTransactionByHash`](https://docs.alchemyapi.io/alchemy/documentation/alchemy-api-reference/json-rpc#eth_gettransactionbyhash), což je požadavek na přečtení informací o naší transakci na základě daného haše. Chcete-li se dozvědět více o odesílání transakcí, podívejte se na [náš tutoriál o odesílání transakcí pomocí Web3](/developers/tutorials/sending-transactions-using-web3-and-alchemy/).