beacon and hare should use the same code to determine eligibility

[countvonzero]

Description

currently tortoise beacon calculate and threshold for VRF signature based on the formula in the research forum thread Tortoise Beacon based on Bad VRF

hare determines eligibility this way https://github.com/spacemeshos/go-spacemesh/blob/cfd428928c92d280525f7a38f59a2935720941ec/hare/eligibility/oracle.go#L290

according to Tal's response in slack dev channel, and R&D recording on 06/01/2021 (2nd video) minute 22:00

for sampling the proposals in the Tortoise beacon, we should do exactly the same as the Hare 
(using the same code, as @noam suggests). The differences are only in the inputs:
- The input to the VRF that creates the "randomness" for sampling in the Hare includes the 
  tortoise beacon for the current epoch; for the tortoise beacon protocol it doesn't (so the input 
  for every epoch is known arbitrarily far into the future).
- The threshold that determines "winning" is set so that we get the desired expected weight of 
  proposals (as opposed to the desired expected weight of a hare-round committee).

what's unclear to me is the efficiency of this approach. in tortoise beacon we should avoid doing this calculation per proposal message, as the upper bound of proposal messages is the number of smeshers.

Expected Behavior

the eligibility calculation should be as efficient as possible

[countvonzero]

cc @noamnelke

[noamnelke]

I agree with your concern @countvonzero. The mechanism we have for Hare eligibility is efficient in the sense that we only do one calculation per message that claims to be eligible. In the Hare, it's expected to have <800 such messages, so this is reasonable (the alternative would be to have to do a check for every vote, each message possibly being eligible for several votes).

This method does NOT provide a way to do an aggregate check across different smeshers.

I think that @tal-m should weigh in on this...

[tal-m]

The eligibility calculation for beacon proposals is performed by each miner:

• once to verify their own VRF. The proposal is only published if it passes the eligibility check.
• once for every published proposal. The eligibility criterion is set such that the expected number of successful (published) proposals is very low (much less than 800).

@noamnelke , @countvonzero --- what am I missing?

[noamnelke]

Ah, then this mechanism is perfect. I originally understood that every smesher in the system could be eligible. As long as that's not the case - we're gravy.

[tal-m]

Every smesher could be eligible, just like in the Hare, but only a very small number actually are in any given epoch --- the point of the VRF mechanism is that miners can check for themselves, so other miners only need to see the successful proofs.