Update EIP-7002: Fix typo on link to CL specs

Merged by EIP-Bot.

EIPS/eip-7002.md

@@ -18,7 +18,7 @@ These new execution layer exit messages are appended to the execution layer bloc
 
 ## Motivation
 
-Validators have two keys -- an active key and a withdrawal credential. The active key takes the form of a BLS key, whereas the withdrawal credential can either be a BLS key (0x00) or an execution layer address (0x01). The active key is "hot", actively signing and performing validator duties, whereas the withdrawal credential can remain "cold", only performing limited operations in relation to withdrawing and ownership of the staked ETH. Due to this security relationship, the withdrawal credential ultimately is the key that owns the staked ETH and any rewards. 
+Validators have two keys -- an active key and a withdrawal credential. The active key takes the form of a BLS key, whereas the withdrawal credential can either be a BLS key (0x00) or an execution layer address (0x01). The active key is "hot", actively signing and performing validator duties, whereas the withdrawal credential can remain "cold", only performing limited operations in relation to withdrawing and ownership of the staked ETH. Due to this security relationship, the withdrawal credential ultimately is the key that owns the staked ETH and any rewards.
 
 As currently specified, only the active key can initiate a validator exit. This means that in any non-standard custody relationships (i.e. active key is separate entity from withdrawal credentials), that the ultimate owner of the funds -- the possessor of the withdrawal credentials -- cannot independently choose to exit and begin the withdrawal process. This leads to either trust issues (e.g. ETH can be "held hostage" by the active key owner) or insufficient work-arounds such as pre-signed exits. Additionally, in the event that active keys are lost, a user should still be able to recover their funds by using their cold withdrawal credentials.
 
@@ -48,7 +48,7 @@ Note, 0x00 withdrawal credentials can be changed into 0x01 withdrawal credential
 | `MAX_EXITS_PER_BLOCK` | 16 | Maximum number of exits that can be dequeued into a block |
 | `TARGET_EXITS_PER_BLOCK` | 2 | |
 | `MIN_EXIT_FEE` | 1 | |
-| `EXIT_FEE_UPDATE_FRACTION` | 17 | | 
+| `EXIT_FEE_UPDATE_FRACTION` | 17 | |
 
 ### Execution layer
 
@@ -125,7 +125,7 @@ def get_exit_fee() -> int:
         excess_exits,
         EXIT_FEE_UPDATE_FRACTION
     )
-    
+
 def fake_exponential(factor: int, numerator: int, denominator: int) -> int:
     i = 1
     output = 0
@@ -167,7 +167,7 @@ def read_exits():
     update_excess_exits()
     reset_exit_count()
     return exits
-    
+
 ###########
 # Helpers #
 ###########
@@ -212,9 +212,9 @@ def update_excess_exits():
     new_excess_exits = 0
     if previous_excess_exits + exit_count > TARGET_EXITS_PER_BLOCK:
         new_excess_exits = previous_excess_exits + exit_count - TARGET_EXITS_PER_BLOCK
-    
+
     sstore(VALIDATOR_EXIT_ADDRESS, EXCESS_EXITS_STORAGE_SLOT, new_excess_exits)
-    
+
 def reset_exit_count():
     sstore(VALIDATOR_EXIT_ADDRESS, EXIT_COUNT_STORAGE_SLOT, 0)
 ```
@@ -515,7 +515,7 @@ block_body_rlp = RLP([
     ...,
     # Latest block body field before `exits`
     field_n,
-    
+
     [exit_0, ..., exit_k],
 ])
 ```
@@ -532,7 +532,7 @@ block.header.exits_root = compute_trie_root_from_indexed_data(block.body.exits)
 
 ### Consensus layer
 
-[Full specification](https://github.com/ethereum/consensus-specs/blob/5d80b1954a4b7a121aa36143d50b366727b66cbc/specs/_features/eip7002/beacon-chain.md>)
+[Full specification](https://github.com/ethereum/consensus-specs/blob/5d80b1954a4b7a121aa36143d50b366727b66cbc/specs/_features/eip7002/beacon-chain.md)
 
 Sketch of spec: