Merge branch 'dev' into refactor/mono-font-static-import

Author: TylerAPfledderer

.all-contributorsrc

@@ -12260,6 +12260,24 @@
       "contributions": [
         "bug"
       ]
+    },
+    {
+      "login": "saurabhburade",
+      "name": "Saurabh Burade",
+      "avatar_url": "https://avatars.githubusercontent.com/u/39492927?v=4",
+      "profile": "https://bsaurabh.xyz/",
+      "contributions": [
+        "code"
+      ]
+    },
+    {
+      "login": "yorkerhodes3",
+      "name": "Yorke E. Rhodes III",
+      "avatar_url": "https://avatars.githubusercontent.com/u/17415717?v=4",
+      "profile": "https://github.com/yorkerhodes3",
+      "contributions": [
+        "content"
+      ]
     }
   ],
   "contributorsPerLine": 7,

.storybook/main.ts

@@ -15,7 +15,10 @@ import type { StorybookConfig } from "@storybook/nextjs"
  */
 
 const config: StorybookConfig = {
-  stories: ["../src/components/**/*.stories.{ts,tsx}"],
+  stories: [
+    "../src/components/**/*.stories.tsx",
+    "../src/layouts/stories/*.stories.tsx",
+  ],
   addons: [
     "@storybook/addon-links",
     "@storybook/addon-essentials",

README.md

@@ -6,7 +6,7 @@
 [![gitpoap badge](https://public-api.gitpoap.io/v1/repo/ethereum/ethereum-org-website/badge)](https://www.gitpoap.io/gh/ethereum/ethereum-org-website)
 
 <div align="center" style="margin-top: 1em; margin-bottom: 3em;">
-  <a href="https://ethereum.org"><img alt="ethereum logo" src="./public/assets/eth-transparent.png" alt="ethereum.org" width="125"></a>
+  <a href="https://ethereum.org"><img alt="ethereum logo" src="./public/images/assets/eth-transparent.png" alt="ethereum.org" width="125"></a>
   <h1>👋 Welcome to ethereum.org!</h1>
 </div>
 
@@ -116,7 +116,7 @@ git push
 - After your changes are committed to your GitHub fork, submit a pull request (PR) to the `dev` branch of the `ethereum/ethereum-org-website` repo
 - In your PR description, reference the issue it resolves (see [linking a pull request to an issue using a keyword](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword))
   - ex. `Updates out of date content [Fixes #1234]`
-- Netlify (our hosting service for build previews) deploys all PRs to a publicly accessible preview URL, e.g.: ![Netlify deploy preview](public/preview-deploy.png)
+- Netlify (our hosting service for build previews) deploys all PRs to a publicly accessible preview URL, e.g.: ![Netlify deploy preview](public/images/preview-deploy.png)
 - _Confirm your Netlify preview deploy looks & functions as expected_
 - Why not say hi and draw attention to your PR in [our discord server](https://discord.gg/ethereum-org)?
 
@@ -136,7 +136,7 @@ Learn more about how we review pull requests [here](docs/review-process.md).
 
 <hr style="margin-top: 3em; margin-bottom: 3em;">
 
-![POAP Logo](public/poap-logo.svg)
+![POAP Logo](public/images/poap-logo.svg)
 
 ## Claim your POAP!
 
@@ -1874,6 +1874,10 @@ Thanks goes to these wonderful people ([emoji key](https://allcontributors.org/d
       <td align="center" valign="top" width="14.28%"><a href="https://github.com/JacobSharples"><img src="https://avatars.githubusercontent.com/u/45126111?v=4?s=100" width="100px;" alt="Jacob Sharples"/><br /><sub><b>Jacob Sharples</b></sub></a><br /><a href="#content-JacobSharples" title="Content">🖋</a></td>
       <td align="center" valign="top" width="14.28%"><a href="https://github.com/omahs"><img src="https://avatars.githubusercontent.com/u/73983677?v=4?s=100" width="100px;" alt="omahs"/><br /><sub><b>omahs</b></sub></a><br /><a href="#translation-omahs" title="Translation">🌍</a></td>
       <td align="center" valign="top" width="14.28%"><a href="https://github.com/Shiva-Sai-ssb"><img src="https://avatars.githubusercontent.com/u/112751524?v=4?s=100" width="100px;" alt="Shiva Sai"/><br /><sub><b>Shiva Sai</b></sub></a><br /><a href="https://github.com/ethereum/ethereum-org-website/issues?q=author%3AShiva-Sai-ssb" title="Bug reports">🐛</a></td>
+      <td align="center" valign="top" width="14.28%"><a href="https://bsaurabh.xyz/"><img src="https://avatars.githubusercontent.com/u/39492927?v=4?s=100" width="100px;" alt="Saurabh Burade"/><br /><sub><b>Saurabh Burade</b></sub></a><br /><a href="https://github.com/ethereum/ethereum-org-website/commits?author=saurabhburade" title="Code">💻</a></td>
+    </tr>
+    <tr>
+      <td align="center" valign="top" width="14.28%"><a href="https://github.com/yorkerhodes3"><img src="https://avatars.githubusercontent.com/u/17415717?v=4?s=100" width="100px;" alt="Yorke E. Rhodes III"/><br /><sub><b>Yorke E. Rhodes III</b></sub></a><br /><a href="#content-yorkerhodes3" title="Content">🖋</a></td>
     </tr>
   </tbody>
 </table>

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

@@ -38,7 +38,7 @@ Do you have a background in mathematics, cryptography, or economics? You might b
 - [Ethresear.ch](https://ethresear.ch) - Ethereum’s primary forum for research, and the world’s most influential forum for cryptoeconomics
 - [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) - An ongoing Q&A series with researchers. As each next part opens, anyone can post questions.
 - [Ecosystem Support Program's wishlist](https://esp.ethereum.foundation/wishlist/) - research areas where the Ethereum Ecosystem Support Program is actively seeking grant applications
-- [AllWalletDevs](allwallet.dev) - a forum for Ethereum developers, designers, and interested users to come together regularly and discuss wallets
+- [AllWalletDevs](https://allwallet.dev) - a forum for Ethereum developers, designers, and interested users to come together regularly and discuss wallets
 
 [Explore more active areas of research](/community/research/).
 

public/content/community/support/index.md

@@ -92,6 +92,7 @@ Most of the teams building Ethereum clients also have dedicated, public-facing,
 - [Nethermind](https://discord.gg/YJx3pm8z5C)
 - [Besu](https://discord.gg/p8djYngzKN)
 - [Erigon](https://github.com/ledgerwatch/erigon/issues)
+- [Reth](https://github.com/paradigmxyz/reth/discussions)
 
 ### Consensus clients {#consensus-clients}
 

public/content/developers/docs/apis/json-rpc/index.md

@@ -74,7 +74,7 @@ The following options are possible for the defaultBlock parameter:
 
 - `HEX String` - an integer block number
 - `String "earliest"` for the earliest/genesis block
-- `String "latest"` - for the latest mined block
+- `String "latest"` - for the latest proposed block
 - `String "safe"` - for the latest safe head block
 - `String "finalized"` - for the latest finalized block
 - `String "pending"` - for the pending state/transactions
@@ -940,7 +940,7 @@ params: [
 
 `DATA`, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.
 
-Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) to get the contract address, after the transaction was mined, when you created a contract.
+Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) to get the contract address, after the transaction was proposed in a block, when you created a contract.
 
 **Example**
 
@@ -973,7 +973,7 @@ params: [
 
 `DATA`, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.
 
-Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) to get the contract address, after the transaction was mined, when you created a contract.
+Use [eth_getTransactionReceipt](#eth_gettransactionreceipt) to get the contract address, after the transaction was proposed in a block, when you created a contract.
 
 **Example**
 
@@ -1412,8 +1412,8 @@ Topics are order-dependent. A transaction with a log with topics [A, B] will be
 
 1. `Object` - The filter options:
 
-- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last mined block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for not yet mined transactions.
-- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last mined block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for not yet mined transactions.
+- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
 - `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
 - `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
 
@@ -1617,8 +1617,8 @@ Returns an array of all logs matching a given filter object.
 
 1. `Object` - The filter options:
 
-- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last mined block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for not yet mined transactions.
-- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last mined block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for not yet mined transactions.
+- `fromBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
+- `toBlock`: `QUANTITY|TAG` - (optional, default: `"latest"`) Integer block number, or `"latest"` for the last proposed block, `"safe"` for the latest safe block, `"finalized"` for the latest finalized block, or `"pending"`, `"earliest"` for transactions not yet in a block.
 - `address`: `DATA|Array`, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.
 - `topics`: `Array of DATA`, - (optional) Array of 32 Bytes `DATA` topics. Topics are order-dependent. Each topic can also be an array of DATA with "or" options.
 - `blockhash`: `DATA`, 32 Bytes - (optional, **future**) With the addition of EIP-234, `blockHash` will be a new filter option which restricts the logs returned to the single block with the 32-byte hash `blockHash`. Using `blockHash` is equivalent to `fromBlock` = `toBlock` = the block number with hash `blockHash`. If `blockHash` is present in the filter criteria, then neither `fromBlock` nor `toBlock` are allowed.
@@ -1722,8 +1722,7 @@ curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": [
 {"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}}
 ```
 
-Our contract was created on `0x4d03d617d700cf81935d7f797f4e2ae719648262`. A null result instead of a receipt means the transaction has
-not been included in a block yet. Wait for a moment and check if your miner is running and retry it.
+Our contract was created on `0x4d03d617d700cf81935d7f797f4e2ae719648262`. A null result instead of a receipt means the transaction has not been included in a block yet. Wait for a moment and check if your consensus client is running and retry it.
 
 #### Interacting with smart contracts {#interacting-with-smart-contract}
 

public/content/developers/docs/consensus-mechanisms/poa/index.md

@@ -22,7 +22,7 @@ There are multiple implementations of PoA, but the standard Ethereum implementat
 
 In PoA, a set of authorized signers are selected to create new blocks. The signers are selected based on their reputation, and they are the only ones allowed to create new blocks. The signers are selected in a round-robin fashion, and each signer is allowed to create a block in a specific time frame. The block creation time is fixed, and the signers are required to create a block within that time frame.
 
-The reputation in this context is not a quantified thing but rather it is the reputation of well-known corporations like Microsoft and Google, hence the way of selecting the trusted signers is not algorithmic but rather it is the normal human act of _trust_ where an entity let's say for example Microsoft creates a PoA private network between hundreds or thousands of startups and the role itself as the only trusted signer with the possibility of adding other well-known signers like Google in the future, the startups would, without doubt, trust Microsoft to act in an honest manner all the times and use the network. This solves the need to stake in different small/private networks that were built for different purposes to keep them decentralized and functioning, along with the need for miners which consumes a lot of power and resources. Some private networks use the PoA standard as it such as VeChain, and some modify it such as Binance which uses [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) which is a custom modified version of PoA and PoS.
+The reputation in this context is not a quantified thing but rather it is the reputation of well-known corporations like Microsoft and Google, hence the way of selecting the trusted signers is not algorithmic but rather it is the normal human act of _trust_ where an entity let's say for example Microsoft creates a PoA private network between hundreds or thousands of startups and the role itself as the only trusted signer with the possibility of adding other well-known signers like Google in the future, the startups would, without doubt, trust Microsoft to act in an honest manner all the times and use the network. This solves the need to stake in different small/private networks that were built for different purposes to keep them decentralized and functioning, along with the need for miners, which consumes a lot of power and resources. Some private networks use the PoA standard as it such as VeChain, and some modify it such as Binance which uses [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) which is a custom modified version of PoA and PoS.
 
 The voting process is done by the signers themselves. Each signer votes for the addition or removal of a signer in their block when they create a new block. The votes are tallied up by the nodes, and the signers are added or removed based on the votes reaching a certain threshold `SIGNER_LIMIT`.
 
@@ -32,7 +32,7 @@ There may be a situation where small forks occur, the difficulty of a block depe
 
 ### Malicious signers {#malicious-signers}
 
-A malicious user could be added to the list of signers, or a signing key/machine might be compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the miners can vote out the malicious user.
+A malicious user could be added to the list of signers, or a signing key/machine might be compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the validators can vote out the malicious user.
 
 ### Censorship {#censorship-attack}
 
@@ -44,9 +44,9 @@ Another small attack vector is malicious signers injecting new vote proposals in
 
 ### Concurrent blocks {#concurrent-blocks}
 
-In a PoA network, When there are N authorized signers, each signer is allowed to mint 1 block out of K, which means that N-K+1 miners are allowed to mint at any given point in time. To prevent these miners from racing for blocks, each signer should add a small random "offset" to the time it releases a new block. Although this process ensures that small forks are rare, occasional forks can still happen, just like mainnet. If a signer is found to be abusing its power and causing chaos, the other signers can vote them out.
+In a PoA network, When there are N authorized signers, each signer is allowed to mint 1 block out of K, which means that N-K+1 validators are allowed to mint at any given point in time. To prevent these validators from racing for blocks, each signer should add a small random "offset" to the time it releases a new block. Although this process ensures that small forks are rare, occasional forks can still happen, just like mainnet. If a signer is found to be abusing its power and causing chaos, the other signers can vote them out.
 
-If for example there are 10 authorized signers and each signer is allowed to create 1 block out of 20, then at any given time, 11 miners can create blocks. To prevent them from racing to create blocks, each signer adds a small random "offset" to the time they release a new block. This reduces the occurrence of small forks but still allows occasional forks, as seen on the Ethereum Mainnet. If a signer misuses their authority and causes disruptions, they can be voted out of the network.
+If for example there are 10 authorized signers and each signer is allowed to create 1 block out of 20, then at any given time, 11 validators can create blocks. To prevent them from racing to create blocks, each signer adds a small random "offset" to the time they release a new block. This reduces the occurrence of small forks but still allows occasional forks, as seen on the Ethereum Mainnet. If a signer misuses their authority and causes disruptions, they can be voted out of the network.
 
 ## Pros and cons {#pros-and-cons}