Merge pull request #11747 from aztecEagle22/fix

Documentation Text Corrections in Ethereum Content

Author: corwintines

src/content/enterprise/private-ethereum/index.md

@@ -23,7 +23,7 @@ Some collaborative efforts to make Ethereum enterprise friendly have been put to
 
 - [Chainstack](https://chainstack.com/) _multi-cloud and multi-protocol Platform as a Service empowering businesses to rapidly build, deploy, and manage decentralized networks and services_
 - [Clearmatics Autonity](https://www.clearmatics.com/about/) _protocol suite that implements p2p protocols and provides client software and infrastructure_
-- [Hyperledger Besu](https://www.hyperledger.org/use/besu) _Open-source Ethereum client developed under the Apache 2.0 license and written in Java, which includes several consensus algorithms including PoW, and PoA (IBFT, IBFT 2.0, Etherhash, and Clique). Its comprehensive permissioning schemes are designed specifically for use in a consortium environment._
+- [Hyperledger Besu](https://www.hyperledger.org/use/besu) _Open-source Ethereum client developed under the Apache 2.0 license and written in Java, which includes several consensus algorithms including PoW, and PoA (IBFT, IBFT 2.0, Ethash, and Clique). Its comprehensive permissioning schemes are designed specifically for use in a consortium environment._
 - [Hyperledger Burrow](https://www.hyperledger.org/projects/hyperledger-burrow) _modular blockchain client with a permissioned smart contract interpreter partially developed to the specification of the Ethereum Virtual Machine (EVM)_
 - [Kaleido](https://kaleido.io/) _full-stack platform for building and running cross-cloud, hybrid enterprise ecosystems_
 - [Quorum](https://consensys.net/quorum/) _an Ethereum-based open source enterprise blockchain platform with advanced enterprise grade features enabling privacy, permissioning and performance_

src/content/guides/how-to-swap-tokens/index.md

@@ -12,7 +12,7 @@ A token swap involves the exchange of two different assets that exist on the Eth
 
 **Prerequisite:**
 
-- have crypto wallet, you can follow this tutorial: [How to: "Register" an Ethereum account](/guides/how-to-create-an-ethereum-account/)
+- have a crypto wallet, you can follow this tutorial: [How to: "Register" an Ethereum account](/guides/how-to-create-an-ethereum-account/)
 - add funds to your wallet
 
 ## 1. Connect your wallet to the decentralized exchange (DEX) of your choice

src/content/guides/how-to-use-a-bridge/index.md

@@ -8,9 +8,9 @@ lang: en
 
 If there is a lot of traffic on Ethereum, it can become expensive. One solution to this is to create new "layers": i.e. different networks which operate in similar ways to Ethereum itself. These so-called Layer 2s help reduce congestion and cost on Ethereum by processing many more transactions at lower fees, and only storing the result of these on Ethereum every so often. As such, these layers 2s enable us to transact with increased speed and decreased costs. Many popular crypto projects are moving to layer 2s because of these benefits. The simplest way to move tokens from Ethereum to layer 2 is to use a bridge.
 
-**Prerequisite:**
+**Prerequisite:** 
 
-- have crypto wallet, you can follow this tutorial: [How to: "Register" an Ethereum account](/guides/how-to-create-an-ethereum-account/)
+- have a crypto wallet, you can follow this tutorial: [How to: "Register" an Ethereum account](/guides/how-to-create-an-ethereum-account/)
 - add funds to your wallet
 
 ## 1. Determine which layer 2 network you want to use

src/content/nft/index.md

@@ -78,7 +78,7 @@ The NFT smart contract can do a few key things:
 
 When someone "creates" or "mints" an NFT, they're basically telling the smart contract to give them ownership of a particular NFT. This information is securely and publicly stored in the blockchain.
 
-Furthermore, the creator of the contract can add extra rules. They might limit how many of a certain NFT can be made or decide that they should get a small royality fee whenever the NFT changes hands.
+Furthermore, the creator of the contract can add extra rules. They might limit how many of a certain NFT can be made or decide that they should get a small royalty fee whenever the NFT changes hands.
 
 ### NFT security {#nft-security}
 

src/content/roadmap/beacon-chain/index.md

@@ -36,7 +36,7 @@ The transition to proof-of-stake made Ethereum significantly more secure and dec
 And using proof-of-stake as consensus mechanism is a foundational component for [the secure, environmentally friendly and scalable Ethereum we have now](/roadmap/vision/).
 
 <InfoBanner emoji=":money_bag:">
-  If you're interested in becoming a validator and helping secure the Ethereum, <a href="/staking/">learn more about staking</a>.
+  If you're interested in becoming a validator and helping secure Ethereum, <a href="/staking/">learn more about staking</a>.
 </InfoBanner>
 
 ### Setting up for sharding {#setting-up-for-sharding}

src/content/roadmap/danksharding/index.md

@@ -69,7 +69,7 @@ Proposer-builder separation is required to prevent individual validators from ha
 
 </ExpandableCard>
 
-<ExpandableCard title="Why does Danksharding require data availability sampling?" eventCateogry="/roadmap/danksharding" eventName="clicked why does danksharding require data availability sampling?">
+<ExpandableCard title="Why does Danksharding require data availability sampling?" eventCategory="/roadmap/danksharding" eventName="clicked why does danksharding require data availability sampling?">
 
 Data availability sampling is required for validators to quickly and efficiently verify blob data. Using data availability sampling, the validators can be very certain that the blob data was available and correctly committed. Every validator can randomly sample just a few data points and create a proof, meaning no validator has to check the entire blob. If any data is missing, it will be identified quickly and the blob rejected.
 

src/content/roadmap/merge/issuance/index.md

@@ -6,7 +6,7 @@ lang: en
 
 # How The Merge impacted ETH supply {#how-the-merge-impacts-ETH-supply}
 
-The Merge represented the Ethereum networks transition from proof-of-work to proof-of-stake which occurred in September 2022. The way ETH was issued underwent changes at time of that transition. Previously, new ETH was issued from two sources: the execution layer (i.e. Mainnet) and the consensus layer (i.e. Beacon Chain). Since The Merge, issuance on the execution layer is now zero. Let's break this down.
+The Merge represented the Ethereum network's transition from proof-of-work to proof-of-stake which occurred in September 2022. The way ETH was issued underwent changes at time of that transition. Previously, new ETH was issued from two sources: the execution layer (i.e. Mainnet) and the consensus layer (i.e. Beacon Chain). Since The Merge, issuance on the execution layer is now zero. Let's break this down.
 
 ## Components of ETH issuance {#components-of-eth-issuance}
 

src/content/roadmap/single-slot-finality/index.md

@@ -44,7 +44,7 @@ In this scheme, it is only possible for every validator to vote on a block by di
 
 Since the Ethereum consensus mechanism was designed, the signature aggregation scheme (BLS) has been found to be far more scalable than was initially thought, while the ability of clients to process and verify signatures has also improved. It turns out that processing attestations from a huge number of validators is actually possible within a single slot. For example, with one million validators each voting twice in each slot, and slot times adjusted to be 16 seconds, nodes would be required to verify signatures at a minimum rate of 125,000 aggregations per second in order to process all 1 million attestations within the slot. In reality, it takes a normal computer around 500 nanoseconds to do one signature verification, meaning 125,000 can be done in ~62.5 ms - far below the one second threshold.
 
-Further efficiency gains could be made by creating supercommittees of e.g. 125,000 randomly selected validators per slot. Only these validators get to vote on a block and therefore only this subset of validators decide whether a block is finalized. Whether this is a good idea or not comes down to how expensive the community would prefer a successful attack on Ethereum to be. This is because instead of requiring 2/3 of the total staked ether, and attacker could finalize a dishonest block with 2/3 of the staked ether _in that supercommittee_. This is still an active area of research, but it seems plausible that for a validator set sufficiently large to require supercommittees in the first place, the cost of attacking one of those subcommittees will be extremely high (e.g. the ETH denominated cost of attack would be `2/3 * 125,000 * 32 = ~2.6 million ETH`). The cost of attack can be adjusted by increasing the size of the validator set (e.g. tune the validator size so the cost of attack is equal to 1 million ether, 4 million ether, 10 million ether, etc). [Preliminary polls](https://youtu.be/ojBgyFl6-v4?t=755) of the community seem to suggest that 1-2 million ether is an acceptable cost of attack, which implies ~65,536 - 97,152 validators per supercommittee.
+Further efficiency gains could be made by creating supercommittees of e.g. 125,000 randomly selected validators per slot. Only these validators get to vote on a block and therefore only this subset of validators decide whether a block is finalized. Whether this is a good idea or not comes down to how expensive the community would prefer a successful attack on Ethereum to be. This is because instead of requiring 2/3 of the total staked ether, an attacker could finalize a dishonest block with 2/3 of the staked ether _in that supercommittee_. This is still an active area of research, but it seems plausible that for a validator set sufficiently large to require supercommittees in the first place, the cost of attacking one of those subcommittees will be extremely high (e.g. the ETH denominated cost of attack would be `2/3 * 125,000 * 32 = ~2.6 million ETH`). The cost of attack can be adjusted by increasing the size of the validator set (e.g. tune the validator size so the cost of attack is equal to 1 million ether, 4 million ether, 10 million ether, etc). [Preliminary polls](https://youtu.be/ojBgyFl6-v4?t=755) of the community seem to suggest that 1-2 million ether is an acceptable cost of attack, which implies ~65,536 - 97,152 validators per supercommittee.
 
 However, verification is not the true bottleneck - it is signature aggregation that really challenges validator nodes. To scale signature aggregation will probably require increasing the number of validators in each subnet, increasing the number of subnets, or adding additional layers of aggregation (i.e. implement committees of committees). Part of the solution might be allowing specialized aggregators - similar to how block building and generating commitments for rollup data will be outsourced to specialized block builders under proposer-builder separation (PBS) and Danksharding.