Skip to content

Commit

Permalink
docs: clarify requestValidatorsDeregistration + deregisterValidators …
Browse files Browse the repository at this point in the history
…behavior w/ associated test
  • Loading branch information
shaspitz committed Jul 18, 2024
1 parent fc1d88c commit 7dbe9eb
Show file tree
Hide file tree
Showing 2 changed files with 37 additions and 2 deletions.
4 changes: 2 additions & 2 deletions contracts/contracts/validator-registry/avs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,11 @@ This function verifies and updates state such that directly after the call, `isV
Note two entities are able to register validator pub keys in this way:

1. The eigenpod owner account itself.
2. The (delegated and registered) Operator account.
2. The (delegated and fully registered) Operator account.

If an Operator is registering pubkeys on behalf of validators, it's expected that the Operator manages those validators itself, or represents the validators to an extent that the Operator can realistically attest to the validator following the rules of mev-commit (staking-as-a-service providers for example). This trustful relationship between validators and their delegated Operator piggybacks off already agreed upon trust assumptions with eigenlayer delegation.

Validator deregistration requires calling `requestValidatorsDeregistration`, waiting a configurable amount of blocks, then calling `deregisterValidators`. These functions are similarly callable by the eigenpod owner OR delegated operator.
Validator deregistration requires calling `requestValidatorsDeregistration`, waiting a configurable amount of blocks, then calling `deregisterValidators`. These functions are similarly callable by the eigenpod owner OR delegated operator. A delegated operator calling either `requestValidatorsDeregistration` or `deregisterValidators` does not require that operator to be registered with the MevCommitAVS (this is allowed due to aforementioned trust assumptions between validators and their delegated Operator).

### What defines a validator staying "opted-in"

Expand Down
35 changes: 35 additions & 0 deletions contracts/test/validator-registry/avs/MevCommitAVSTest.sol
Original file line number Diff line number Diff line change
Expand Up @@ -1042,4 +1042,39 @@ contract MevCommitAVSTest is Test {
assertTrue(mevCommitAVS.isValidatorOptedIn(valPubkeys[0]));
assertTrue(mevCommitAVS.isValidatorOptedIn(valPubkeys[1]));
}

function testDeregisteredOperatorCanStillDeregisterValidators() public {
testRegisterValidatorsByPodOwners();

address operator = address(0x888);
vm.prank(operator);
mevCommitAVS.requestOperatorDeregistration(operator);
assertTrue(mevCommitAVS.getOperatorRegInfo(operator).exists);
assertTrue(mevCommitAVS.getOperatorRegInfo(operator).deregRequestHeight.exists);

bytes[] memory valPubkeys = new bytes[](2);
valPubkeys[0] = bytes("valPubkey1");
valPubkeys[1] = bytes("valPubkey2");

address podOwner = address(0x420);
vm.expectEmit(true, true, true, true);
emit ValidatorDeregistrationRequested(valPubkeys[0], podOwner);
vm.expectEmit(true, true, true, true);
emit ValidatorDeregistrationRequested(valPubkeys[1], podOwner);
vm.prank(operator);
mevCommitAVS.requestValidatorsDeregistration(valPubkeys);

vm.roll(2000);

vm.prank(operator);
mevCommitAVS.deregisterOperator(operator);
assertFalse(mevCommitAVS.getOperatorRegInfo(operator).exists);

vm.expectEmit(true, true, true, true);
emit ValidatorDeregistered(valPubkeys[0], podOwner);
vm.expectEmit(true, true, true, true);
emit ValidatorDeregistered(valPubkeys[1], podOwner);
vm.prank(operator);
mevCommitAVS.deregisterValidators(valPubkeys);
}
}

0 comments on commit 7dbe9eb

Please sign in to comment.