Computing proposers is not cached

[wemeetagain]

@dapplion this won't cache though, and on every request to get next proposers, the this.proposersNextEpoch.computed check here will always return false, and the if branch check always run.

You can confirm this by running the application, and trigger the end point multiple times, the if branch will always run.

I noticed this while working on the implementation and I think the reason why this is the case is how the chain.getHeadStateAtCurrentEpoch here works, but I did not go ahead with caching when I realised that the request to the endpoint itself was actually pretty fast and no need to even cache.

Originally posted by @dadepo in #3782 (comment)

[dadepo]

Locally with the code modified as follows:

  getBeaconProposersNextEpoch(): ValidatorIndex[] {
    if (!this.proposersNextEpoch.computed) {
      console.log("should only console once. Current epoch is: " + this.epoch);
      const indexes = computeProposers(
        this.proposersNextEpoch.seed,
        this.nextShuffling,
        this.effectiveBalanceIncrements
      );
      this.proposersNextEpoch = {computed: true, indexes};
    }

    return this.proposersNextEpoch.indexes;
  }

At current epoch of 94955, making repeated requests for proposers at 94956, the console:

May-19 16:34:06.001[]                 info: Synced - slot: 3038570 - head: 3038570 0x1879…e5c1 - finalized: 0x2b30…d099:94953 - peers: 10
should only console once. Current epoch is: 94955
May-19 16:34:18.001[]                 info: Synced - slot: 3038571 - head: 3038571 0x3517…6ea6 - finalized: 0x2b30…d099:94953 - peers: 9
should only console once. Current epoch is: 94955
should only console once. Current epoch is: 94955
should only console once. Current epoch is: 94955

[dapplion]

I tested this feature and was unable to request duties for the next epoch since this function throws for any slot ahead of the clock

lodestar/packages/lodestar/src/api/impl/validator/index.ts

Line 277 in ab35439

await waitForSlot(startSlot); // Must never request for a future slot > currentSlot

@dadepo How were you able to test the feature? That check has always been there

• After fixing it with this PR Allow to request proposer duties for next epoch #4941

Caching works fine, adding manually a console.log I can see that next proposers is computed only once for repeated calls through that epoch. So closing the issue