Improve wiki pages: fix typos and expand protocol history

docs/wiki/CL/cl-networking.md

@@ -248,7 +248,7 @@ This separation matters because discovery and transport have different constrain
 
 ### Security and handshake
 
-discv5 does not send discovery traffic as plain unauthenticated UDP. Ordinary packets are encrypted and authenticated, and when a node cannot decrypt a message from an endpoint it answers with a `WHOAREYOU` challenge instead of blindly returning discovery data. This forces the initiator to prove control of its node identity and establish fresh session keys before the recipient accepts requests such as `FINDNODE`.
+discv5 does not send discovery traffic as plain unauthenticated UDP. Ordinary packets are encrypted and authenticated, and when a node cannot `decrypt` a message from an endpoint it answers with a `WHOAREYOU` challenge instead of blindly returning discovery data. This forces the initiator to prove control of its node identity and establish fresh session keys before the recipient accepts requests such as `FINDNODE`.
 
 At a high level, the exchange works as follows:
 

docs/wiki/EL/el-architecture.md

@@ -249,7 +249,7 @@ The execution layer has its own consensus engine to work with its own copy of th
 |                                                                                                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                         | Set the header difficulty based on the signer's turn (2 if the signer is in turn and 1 if not)                                                                                                                                                                                                                                                                                                                                                                                                                            |                        |
 |                                                                                                                                                 |                                                                                                                                                                                                                                                                                                                                                                                                                                                         | Verify that the extraData contains all the necessary elements, including extraVanity and a list of signers if the block occurs at the end of the epoch. This is added to the Header's extraData field.                                                                                                                                                                                                                                                                                                                    |                        |
 | **Finalize**: After making changes to the state, the state database may be updated, but this action does not involve the assembly of the block. | If the header is not a Proof-of-stake header, we execute the finalize function of ethone. Otherwise, we loop through the withdrawals in the block, converting their amounts from wei to gwei. We then modify the state by adding the converted amount to the address associated with the current withdrawal.                                                                                                                                            | Clique has no post-transaction consensus rules, no block rewards in proof of authority                                                                                                                                                                                                                                                                                                                                                                                                                                    |                        |
-| **FinalizeAndAssemble**: Finalizes and assemble the final block                                                                                 | If the header is not a Proof-of-stake header, we invoke ethone's FinalizeAndAssemble. If there are no withdrawals and the block is after the Shanghai fork, we include an empty withdrawals object. Next, we invoke the finalize function to calculate the state root. We then assign this value to the root property of the header object. Finally, we construct a new block by combining the header, transactions, uncles, receipts, and withdrawals. | Verify that there are no withdrawals, invoke the finalize function, calculate the state root of our stateDB, and assign it to the the Header . Construct a new block using the header, transactions, and receipts.                                                                                                                                                                                                                                                                                                        |                        |
+| **FinalizeAndAssemble**: Finalizes and assemble the final block                                                                                 | If the header is not a Proof-of-stake header, we invoke ethone's FinalizeAndAssemble. If there are no withdrawals and the block is after the Shanghai fork, we include an empty withdrawals object. Next, we invoke the finalize function to calculate the state root. We then assign this value to the root property of the header object. Finally, we construct a new block by combining the header, transactions, uncles, receipts, and withdrawals. | Verify that there are no withdrawals, invoke the finalize function, calculate the state root of our stateDB, and assign it to the Header . Construct a new block using the header, transactions, and receipts.                                                                                                                                                                                                                                                                                                        |                        |
 | **Seal**: Generates a sealing request for a block and pushes the request into the given channel                                                 | If the header is not a Proof-of-stake header, we invoke ethone's seal. Otherwise, we take no action and return nil. The verification of the seal is performed by the consensus layer.                                                                                                                                                                                                                                                                   | Make sure that the block is not the initial block, obtain the snapshot, and confirm that we have the authority to sign and are not included in the list of recent signers. Coordinate the timing of our respective turns, apply the sign function to  sign, and transmit the securely sealed block through the designated channel.                                                                                                                                                                                        |                        |
 | **SealHash**: Hash of the block prior to sealing                                                                                                |                                                                                                                                                                                                                                                                                                                                                                                                                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |                        |
 | **CalcDifficulty**: Difficulty adjustment algorithm, returns the difficulty of the new block                                                    |                                                                                                                                                                                                                                                                                                                                                                                                                                                         |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |                        |

docs/wiki/protocol/history.md

@@ -55,6 +55,22 @@ Learn more about Homestead in the following resources:
 - [The Robustness Principle Reconsidered](https://queue.acm.org/detail.cfm?id=1999945)
 - [Homestead blog release post](https://blog.ethereum.org/2016/02/29/homestead-release)
 - [The Homestead release - github](https://github.com/ethereum/homestead-guide/blob/master/source/introduction/the-homestead-release.rst)
+
+ ## London
+
+ The London upgrade, which went live on August 5, 2021, introduced several significant changes to the Ethereum protocol, most notably [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559). EIP-1559 overhauled Ethereum's fee market by replacing the first-price auction model with a base fee and a tip. The base fee is automatically adjusted by the protocol based on network demand and is burned, reducing the total supply of Ether. This change was aimed at making transaction fees more predictable and aligning the incentives of the network with those of its users.
+
+ Other EIPs included in the London upgrade:
+ - [EIP-3198](https://eips.ethereum.org/EIPS/eip-3198): Adds the `BASEFEE` opcode, which returns the base fee of the current block.
+ - [EIP-3529](https://eips.ethereum.org/EIPS/eip-3529): Reduces gas refunds to improve network stability.
+ - [EIP-3541](https://eips.ethereum.org/EIPS/eip-3541): Rejects new contracts starting with the `0xEF` byte, paving the way for future EVM improvements.
+ - [EIP-3554](https://eips.ethereum.org/EIPS/eip-3554): Delays the difficulty bomb.
+
+ Learn more about London in the following resources:
+ - [Ethereum London Upgrade](https://ethereum.org/en/history/#london)
+ - [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559)
+ - [London Mainnet Announcement](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement)
+
 
 ## The Merge
 

docs/wiki/research/PBS/ET.md

@@ -17,7 +17,7 @@ Recent proposals and development towards enshrining Proposer-Builder Separation
 
 ## Attester-Proposer Separation (APS) a.k.a. Validator-Proposer Separation
 
-MEV-boost is an out-of-protocol side-car, outside of the protocol's reach and control. This limitation is addressed within the context of PBS, by the [APS](#attester-proposer-separation-aps-aka-validator-proposer-separation-design-rationale) (Attester-Proposer Separation) design philosophy with the aim of getting some of this infrastructure back into the the protocol's fold. 
+MEV-boost is an out-of-protocol side-car, outside of the protocol's reach and control. This limitation is addressed within the context of PBS, by the [APS](#attester-proposer-separation-aps-aka-validator-proposer-separation-design-rationale) (Attester-Proposer Separation) design philosophy with the aim of getting some of this infrastructure back into the protocol's fold. 
 
 APS design rationale is closely related to **ePBS - enshrined Proposer-Builder Separation** design space.
 

docs/wiki/research/PBS/mev.md

@@ -1,6 +1,6 @@
 # Maximal Extractable Value (previously Miner Extractable Value)
 
-Maximal Extractable Value (MEV) refers to the the maximum value that can be extracted from block production beyond the standard block reward and gas fees by strategically ordering, including, or excluding transactions in a block.
+Maximal Extractable Value (MEV) refers to the maximum value that can be extracted from block production beyond the standard block reward and gas fees by strategically ordering, including, or excluding transactions in a block.
 
 In Ethereum, MEV has gained greater attention as validators extract increasingly more value, especially in DeFi (Decentralized Finance) applications. Arbitrage opportunities facilitated by strategies like front-running, sandwiching or back-running are possible by ordering transactions in the block. This can also lead to negative consequences, such as unfair advantages for large-scale pools, censorship or increased slippage for DeFi users.
 

docs/wiki/research/history-expiry/history-expiry.md

@@ -34,9 +34,9 @@ Under `eth/68` and older `eth` protocols, nodes assumed every peer stored the fu
 
 `eth/69` also adds a new message, BlockRangeUpdate. As a node prunes more data or downloads more history, it sends this message to its connected peers so they can update their view of what blocks that node can serve. This only needs to be sent once per epoch.
 
-`eth/69`'s linear range works for Phase 1 where nodes either hold pre-Merge (old PoW chain) data or they don't. For Phase 2, where nodes may hold non-contiguous slices of history, proposals like [EIP-7801](https://eips.ethereum.org/EIPS/eip-7801), introduce a bitmask-based subprotocol called `etha` that lets nodes advertise exactly which segments of the chain they store. While the eth protocol continues to handle live chain operations like block propagation, transaction gossip, and syncing to the tip, the `etha` subprotocol is dedicated entirely to serving historical data. This means historical block requests will no longer travel over the same channel as live chain, so a node that is looking for old blocks queries peers over etha, and nodes that do not support history sharding are never bothered with those requests again.
+`eth/69`'s linear range works for Phase 1 where nodes either hold pre-Merge (old PoW chain) data or they don't. For Phase 2, where nodes may hold non-contiguous slices of history, proposals like [EIP-7801](https://eips.ethereum.org/EIPS/eip-7801), introduce a `bitmask`-based subprotocol called `etha` that lets nodes advertise exactly which segments of the chain they store. While the eth protocol continues to handle live chain operations like block propagation, transaction gossip, and syncing to the tip, the `etha` subprotocol is dedicated entirely to serving historical data. This means historical block requests will no longer travel over the same channel as live chain, so a node that is looking for old blocks queries peers over etha, and nodes that do not support history sharding are never bothered with those requests again.
 
-The core idea of `etha` is that the chain history will be divided into repeating windows of 1,064,960 blocks. Each window is split into 10 equal spans of 106,496 blocks. Each bit in the bitmask represents one of those spans. If a node sets bit 3, that node is committing to hold every third span out of ten not just in the segment alone, but the entire chain from blocks 0 through 1,064,960, and from blocks 1,064,960 through 2,129,920, and so on all the way to the chain head. As new blocks are produced and new spans are created, the node must continue storing the spans that correspond to its committed bit.
+The core idea of `etha` is that the chain history will be divided into repeating windows of 1,064,960 blocks. Each window is split into 10 equal spans of 106,496 blocks. Each bit in the `bitmask` represents one of those spans. If a node sets bit 3, that node is committing to hold every third span out of ten not just in the segment alone, but the entire chain from blocks 0 through 1,064,960, and from blocks 1,064,960 through 2,129,920, and so on all the way to the chain head. As new blocks are produced and new spans are created, the node must continue storing the spans that correspond to its committed bit.
 
 **Window: Blocks 0 — 1,064,960**