Merge branch 'master' into alex/docs-eigenpod-fixes

certora/specs/core/StrategyManager.spec

@@ -134,7 +134,7 @@ invariant totalSharesGeqSumOfShares(address strategy)
 
 /**
  * Verifies that ERC20 tokens are transferred out of the account only of the msg.sender.
- * Called 'safeApprovalUse' since approval-related vulnerabilites in general allow a caller to transfer tokens out of a different account.
+ * Called 'safeApprovalUse' since approval-related vulnerabilities in general allow a caller to transfer tokens out of a different account.
  * This behavior is not always unsafe, but since we don't ever use it (at present) we can do a blanket-check against it.
  */
 rule safeApprovalUse(address user) {

docs/core/DelegationManager.md

@@ -273,7 +273,7 @@ For each strategy/share pair in the `Withdrawal`:
     * Shares are also delegated to the originator's Operator, rather than the `withdrawer's` Operator.
     * Shares received by the originator may be lower than the shares originally withdrawn if the originator has debt.
 * `EigenPodManager` withdrawals received as tokens:
-    * Before the withdrawal can be completed, the originator needs to prove that a withdrawal occured on the beacon chain (see [`EigenPod.verifyAndProcessWithdrawals`](./EigenPodManager.md#eigenpodverifyandprocesswithdrawals)).
+    * Before the withdrawal can be completed, the originator needs to prove that a withdrawal occurred on the beacon chain (see [`EigenPod.verifyAndProcessWithdrawals`](./EigenPodManager.md#eigenpodverifyandprocesswithdrawals)).
 
 *Effects*:
 * The hash of the `Withdrawal` is removed from the pending withdrawals

docs/core/EigenPodManager.md

@@ -53,7 +53,7 @@ The functions of the `EigenPodManager` and `EigenPod` contracts are tightly link
 
 #### Important Definitions
 
-* "Pod Owner": A Staker who has deployed an `EigenPod` is a Pod Owner. The terms are used interchangably in this document.
+* "Pod Owner": A Staker who has deployed an `EigenPod` is a Pod Owner. The terms are used interchangeably in this document.
     * Pod Owners can only deploy a single `EigenPod`, but can restake any number of beacon chain validators from the same `EigenPod`.
     * Pod Owners can delegate their `EigenPodManager` shares to Operators (via `DelegationManager`).
     * These shares correspond to the amount of provably-restaked beacon chain ETH held by the Pod Owner via their `EigenPod`.
@@ -436,7 +436,7 @@ function verifyAndProcessWithdrawals(
 Anyone (not just the Pod Owner) can call this method to prove that one or more validators associated with an `EigenPod` have performed a full or partial withdrawal from the beacon chain. 
 
 Whether each withdrawal is a full or partial withdrawal is determined by the validator's "withdrawable epoch" in the `Validator` container given by `validatorFields` (see [consensus specs](https://eth2book.info/capella/part3/containers/dependencies/#validator)). If the withdrawal proof timestamp is after this epoch, the withdrawal is a full withdrawal.
-* Partial withdrawals are performed automatically by the beacon chain when a validator has an effective balance over 32 ETH. This method can be used to prove that these withdrawals occured, allowing the Pod Owner to withdraw the excess ETH (via [`DelayedWithdrawalRouter.createDelayedWithdrawal`](#delayedwithdrawalroutercreatedelayedwithdrawal)).
+* Partial withdrawals are performed automatically by the beacon chain when a validator has an effective balance over 32 ETH. This method can be used to prove that these withdrawals occurred, allowing the Pod Owner to withdraw the excess ETH (via [`DelayedWithdrawalRouter.createDelayedWithdrawal`](#delayedwithdrawalroutercreatedelayedwithdrawal)).
 * Full withdrawals are performed when a Pod Owner decides to fully exit a validator from the beacon chain. To do this, the Pod Owner should follow these steps: 
     1. Undelegate or queue a withdrawal (via the `DelegationManager`: ["Undelegating and Withdrawing"](./DelegationManager.md#undelegating-and-withdrawing))
     2. Exit their validator from the beacon chain and provide a proof to this method

docs/outdated/EigenPods.md

@@ -46,7 +46,7 @@ In the case that a validator's balance, when run through the hysteresis function
 
 ### Proofs of Full/Partial Withdrawals
 
-Whenever a staker withdraws one of their validators from the beacon chain to provide liquidity, they have a few options. Stakers could keep the ETH in the EigenPod and continue staking on EigenLayer, in which case their ETH, when withdrawn to the EigenPod, will not earn any additional Ethereum staking rewards, but may continue to earn rewards on EigenLayer. Stakers could also queue withdrawals on EigenLayer for their virtual beacon chain ETH strategy shares, which will be fullfilled once their obligations to EigenLayer have ended and their EigenPod has enough balance to complete the withdrawal.
+Whenever a staker withdraws one of their validators from the beacon chain to provide liquidity, they have a few options. Stakers could keep the ETH in the EigenPod and continue staking on EigenLayer, in which case their ETH, when withdrawn to the EigenPod, will not earn any additional Ethereum staking rewards, but may continue to earn rewards on EigenLayer. Stakers could also queue withdrawals on EigenLayer for their virtual beacon chain ETH strategy shares, which will be fulfilled once their obligations to EigenLayer have ended and their EigenPod has enough balance to complete the withdrawal.
 
 In this second case, in order to withdraw their balance from the EigenPod, stakers must provide a valid proof of their full withdrawal or partial withdrawal (withdrawals of beacon chain rewards).  In the case of the former, withdrawals are processed via the queued withdrawal system while in the latter, the balance is instantly withdrawable (as it is technically not being restaked). We distinguish between partial and full withdrawals by checking the `validator.withdrawableEpoch`.  If the `validator.withdrawableEpoch <= executionPayload.slot/SLOTS_PER_EPOCH` then it is classified as a full withdrawal (here `executionPayload` contains the withdrawal being proven).  This is because the `validator.withdrawableEpoch` is set when a validator submits a signed exit transaction.  It is only after this that their withdrawal can be picked up by a sweep and be processed.  In the case of a partial withdrawal, `validator.withdrawableEpoch` is set to FFE (far future epoch). 
 

src/contracts/core/Slasher.sol

@@ -428,7 +428,7 @@ contract Slasher is Initializable, OwnableUpgradeable, ISlasher, Pausable {
 
     /**
      * @notice records the most recent updateBlock for the currently updating middleware and appends an entry to the operator's list of
-     *         MiddlewareTimes if relavent information has updated
+     *         MiddlewareTimes if relevant information has updated
      * @param operator the entity whose stake update is being recorded
      * @param updateBlock the block number for which the currently updating middleware is updating the serveUntilBlock for
      * @param serveUntilBlock the block until which the operator's stake at updateBlock is slashable

src/contracts/middleware/BLSPublicKeyCompendium.sol

@@ -50,7 +50,7 @@ contract BLSPublicKeyCompendium is IBLSPublicKeyCompendium {
 
         require(
             shouldBeZero.X == 0 && shouldBeZero.Y == 0,
-            "BLSPublicKeyCompendium.registerBLSPublicKey: incorrect schnorr singature"
+            "BLSPublicKeyCompendium.registerBLSPublicKey: incorrect schnorr signature"
         );
 
         // verify that the G2 pubkey has the same discrete log as the G1 pubkey

src/contracts/middleware/BLSSignatureChecker.sol

@@ -123,7 +123,7 @@ abstract contract BLSSignatureChecker {
      * calldataload - this implementation saves us one ecAdd operation, which would be performed in the i=0 iteration otherwise.
      * Within the loop, each non-signer public key is loaded from the calldata into memory.  The most recent staking-related information is retrieved and is subtracted
      * from the total stake of validators in the quorum.  Then the aggregate public key and the aggregate non-signer public key is subtracted from it.
-     * Finally  the siganture is verified by computing the elliptic curve pairing.
+     * Finally  the signature is verified by computing the elliptic curve pairing.
      */
     function checkSignatures(
         bytes calldata data

src/contracts/middleware/RegistryBase.sol

@@ -241,7 +241,7 @@ abstract contract RegistryBase is VoteWeigherBase, IQuorumRegistry {
     ) external view returns (bool) {
         // fetch the `operator`'s pubkey hash
         bytes32 pubkeyHash = registry[operator].pubkeyHash;
-        // special case for `pubkeyHashToStakeHistory[pubkeyHash]` having lenght zero -- in which case we know the operator was never registered
+        // special case for `pubkeyHashToStakeHistory[pubkeyHash]` having length zero -- in which case we know the operator was never registered
         if (pubkeyHashToStakeHistory[pubkeyHash].length == 0) {
             return true;
         }