post-merge updates: contract size tutorial

src/content/developers/docs/accounts/index.md

@@ -97,6 +97,12 @@ Example:
 
 The contract address is usually given when a contract is deployed to the Ethereum Blockchain. The address comes from the creator's address and the number of transactions sent from that address (the “nonce”).
 
+## Validator keys {#validators-keys}
+
+There is also another type of key in Ethereum, introduced when Ethereum switched from proof-of-work to proof-of-stake based consensus. These are 'BLS' keys and they are used to identify validators. These keys can be efficiently aggregated to reduce the bandwidth required for the network to come to consensus. Without this key aggregation the minimum stake for a validator would be much higher.
+
+[More on validator keys](/developers/docs/consensus-mechanisms/pos/keys/).
+
 ## A note on wallets {#a-note-on-wallets}
 
 An account is not a wallet. An account is the keypair for a user-owned Ethereum account. A wallet is an interface or application that lets you interact with your Ethereum account.

src/content/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/index.md

@@ -19,7 +19,7 @@ On [November 22, 2016](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spuri
 
 This limit was introduced to prevent denial-of-service (DOS) attacks. Any call to a contract is relatively cheap gas-wise. However, the impact of a contract call for Ethereum nodes increases disproportionately depending on the called contract code's size (reading the code from disk, pre-processing the code, adding data to the Merkle proof). Whenever you have such a situation where the attacker requires few resources to cause a lot of work for others, you get the potential for DOS attacks.
 
-Originally this was less of a problem, because one natural contract size limit is the block gas limit. Obviously a contract needs to be deployed within a transaction that holds all of the contract's bytecode. If you then include only that one transaction into a block, you can use up all of that gas, but it's not infinite. The issue in that case though is that the block gas limit changes over time and is in theory unbounded. At the time of the EIP-170 the block gas limit was only 4.7 million. Now the block gas limit just [increased again](https://etherscan.io/chart/gaslimit) last month to 11.9 million.
+Originally this was less of a problem, because one natural contract size limit is the block gas limit. Obviously a contract needs to be deployed within a transaction that holds all of the contract's bytecode. If you then include only that one transaction into a block, you can use up all of that gas, but it's not infinite. Since EIP-1559 the block gas limit has been able to vary between 12.5M and 25M units depending on network demand.
 
 ## Taking on the fight {#taking-on-the-fight}
 
@@ -146,9 +146,3 @@ function doSomething() { checkStuff(); }
 ```
 
 Those tips should help you to significantly reduce the contract size. Once again, I cannot stress enough, always focus on splitting contracts if possible for the biggest impact.
-
-## The future for the contract size limits {#the-future-for-the-contract-size-limits}
-
-There is an [open proposal](https://github.com/ethereum/EIPs/issues/1662) to remove the contract size limit. The idea is basically to make contract calls more expensive for large contracts. It wouldn't be too difficult to implement, has a simple backwards compatibility (put all previously deployed contracts in the cheapest category), but [not everyone is convinced](https://ethereum-magicians.org/t/removing-or-increasing-the-contract-size-limit/3045/24).
-
-Only time will tell if those limits will change in the future, the reactions (see image on the right) definitely show a clear requirement for us developers. Unfortunately, it is not something you can expect any time soon.