feat: instant alloc delay from dm

[ypatil12]

Motivation:

Newly created operators in core have to wait 17.5 days to begin allocating. This is a UX painpoint for new AVSs to onboard their operators.

Modifications:

Update the AllocationManager so that the allocation delay for a newly created operator is active at the next block. This allows operators to make an allocation at the very next block.

Result:

Easier onboarding

[nadir-akhtar]

Rather than passing in an arbitrary uint32, which we expect to be constrained to either 0 or ALLOCATION_CONFIGURATION_DELAY based on whether this is an operator's first registration or subsequent registration respectively, I recommend instead using existing storage within this function to determine what effectBlock to set.

info.effectBlock is 0 before registration, and non-zero after registration. By checking within this function if info.effectBlock == 0, we can then set the new effectBlock accordingly: uint32(block.number) + 1 if true, uint32(block.number) + ALLOCATION_CONFIGURATION_DELAY + 1 if false. This constrains the function inputs to as few as possible, and allows the internal function to figure out the correct delay for the operator.

Side question: is having the delay activate on the block following this call a consequence of the implementation, or is there a safety or other concern meriting it?

[ypatil12]

Good points. I think we cannot do the effectBlock == 0 check because we only want newly registered operators (in core) to be able to allocate after a single block. However, if we checked effectBlock==0, then both newly registered operators and operators that have previously registered, but not used slashing, could allocate instantly, which we don't want. Thoughts on passing in a bool instead?

I kept +1 for consistency with the old implementation. Though, it remains to be seen if we want an immediate allocation (same block)

[ypatil12]

d96438b

[nadir-akhtar]

Good callout on already existing operators requiring a different flow! The boolean approach makes total sense.

There's a slight optimization you can do for codesize by removing the newlyRegistered = false statement (since it'll already be false by default). But other than that, looks solid.

[ypatil12]

True, will remove

[ypatil12]

3503884

[nadir-akhtar]

Looked over it again, here's what I think the cleanest implementation is, for most clarity and least codesize:

    function setAllocationDelay(address operator, uint32 delay) external {
        /// If the caller is the delegationManager, the operator is newly registered
        /// This results in *newly-registered* operators in the core protocol to have their allocation delay effective after 1 block
        bool newlyRegistered = (msg.sender != address(delegation));

        if (!newlyRegistered) {
            require(_checkCanCall(operator), InvalidCaller());
            require(delegation.isOperator(operator), InvalidOperator());
        }

        _setAllocationDelay(operator, delay, newlyRegistered);
    }

[ypatil12]

Cleaner! Updated: 3850113