Update EIP-4788: 4788 cleanups

Merged by EIP-Bot.

EIPS/eip-4788.md

@@ -117,7 +117,7 @@ def get():
 
     root_idx = timestamp_idx + HISTORY_BUFFER_LENGTH
     root = storage.get(root_idx)
-    
+
     evm.return(root)
 
 def set():
@@ -240,14 +240,11 @@ If this EIP is active in a genesis block, the genesis header's `parent_beacon_bl
 
 ## Rationale
 
-### Gas cost of precompile
-
-The suggested gas cost reflects a cold `SLOAD` analogous to the operation(s) performed while executing the precompile's logic.
-
 ### Why not repurpose `BLOCKHASH`?
 
 The `BLOCKHASH` opcode could be repurposed to provide the beacon root instead of some execution block hash.
-To minimize code change, avoid breaking changes to smart contracts, and simplify deployment to mainnet, this EIP suggests leaving `BLOCKHASH` alone and adding a new precompile with the desired semantics.
+To minimize code change, avoid breaking changes to smart contracts, and simplify deployment to mainnet, this EIP suggests leaving `BLOCKHASH` alone and adding new
+functionality with the desired semantics.
 
 ### Beacon block root instead of state root
 
@@ -261,7 +258,7 @@ e.g. with a singleton state root contract that caches the proof per slot).
 ### Why two ring buffers?
 
 The first ring buffer only tracks `HISTORY_BUFFER_LENGTH` worth of roots and so for all possible timestamp values would consume a constant amount of storage.
-However, this design opens the precompile to an attack where a skipped slot that has the same value modulo the ring buffer length would return an old root value,
+However, this design opens the contract to an attack where a skipped slot that has the same value modulo the ring buffer length would return an old root value,
 rather than the most recent one.
 
 To nullify this attack while retaining a fixed memory footprint, this EIP keeps track of the pair of data `(parent_beacon_block_root, timestamp)` for each index into the