Skip to content

Conversation

@ypatil12
Copy link
Collaborator

@ypatil12 ypatil12 commented May 1, 2025

Motivation:

It is possible to break the maxOperatorCount invariant by doing the following:

Let's assume there are two quorums, 1 and 2, with a maxOperatorCount of 2.

  1. Alice & Bob register for quorum 1
  2. Bob registers for quorum 2
  3. Bob deregisters from quorum 1, Charlie enters
  4. Quorum 1 Members: Alice/Charlie. Quorum 2 members: Bob
  5. Eve creates a churn registration that exits Bob. Quorum 1 has 3 members. This works just fine since we allow a churn to occur if the operatorToKick is registered to the AVS (not the quorum):
    // Check if operator is registered for all quorums we're trying to remove them from
    if (quorumsToRemove.isSubsetOf(currentBitmap)) {
    _forceDeregisterOperator(operator, quorumNumbers);
    }

Although this assumes that the churnApprover is buggy, we should still be enforcing that you are churning a user if they are registered for the quorum.

Modifications:

Require that the operatorToKick is registered for the quorum.

Result:

Stricter churn guarantees.

@ypatil12 ypatil12 requested review from pakim249CAL and wadealexc May 1, 2025 02:32
Copy link
Contributor

@wadealexc wadealexc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ypatil12 ypatil12 merged commit 9a4ffb5 into dev May 1, 2025
5 checks passed
@ypatil12 ypatil12 deleted the hexens/eigen2-5 branch May 1, 2025 16:14
@ypatil12 ypatil12 restored the hexens/eigen2-5 branch May 1, 2025 17:02
ypatil12 added a commit that referenced this pull request May 1, 2025
NOTE: #464 was merged to wrong target

**Motivation:**

It is possible to break the `maxOperatorCount` invariant by doing the
following:

Let's assume there are two quorums, 1 and 2, with a `maxOperatorCount`
of 2.

1. Alice & Bob register for quorum 1
2. Bob registers for quorum 2
3. Bob deregisters from quorum 1, Charlie enters
4. Quorum 1 Members: Alice/Charlie. Quorum 2 members: Bob
5. Eve creates a churn registration that exits Bob. Quorum 1 has 3
members. This works just fine since we allow a churn to occur if the
`operatorToKick` is registered to the AVS (not the quorum):
https://github.com/Layr-Labs/eigenlayer-middleware/blob/f5adbcac55d9336cd646ce71bc467aa7e20f1a12/src/SlashingRegistryCoordinator.sol#L405-L408

Although this assumes that the `churnApprover` is buggy, we should still
be enforcing that you are churning a user if they are registered for the
quorum.

**Modifications:**

Require that the `operatorToKick` is registered for the quorum. 

**Result:**

Stricter churn guarantees.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants