Implement Snarked Uptime Tracker Filtering to Prevent Block Producers running Multiple Keys for the Delegation Program

[GistKen]

A prevalent concern within the Delegation Program consists of an individual running multiple Block Producer keys and claiming to be different individuals in the hopes of obtaining delegation. A potential identifier of these cases is that it would be likely for an individual to use the same machine or IP address but have several block producers running with different keys.

Taking a look at the data Snarked Uptime Tracker, the following fields are available in the cloud storage:

submissions
    - <submitter>/<block_hash>/<created_at>.json
        - File contents:
           - submitted_at with server's timestamp (of the time of submission)
           - remote_addr with the ip:port address from which request has come
           - peer_id (as in user's JSON submission)
           - snark_work (optional, as in user's JSON submission)
           - <submitter> is base58check-encoded submitter's public key
        - <created_at> is UTC-based RFC-3339 -encoded
        - <block_hash> is base64check-encoded hash of a block
blocks
        - <block-hash> .dat
          Contains raw block

As the json file consists of the ip and port for the block producer, would it be feasible to use the combination of the remote IP address and the block producer key to identify people who run multiple block producer keys?

For instance, if the validation service sees two different block producer keys originating from the same IP address, it may be valid to assume that the person is running two block producer keys.
In instances in which the validation service sees the same block producer key twice within a 5 minute period, it would process it as normal as this likely indicates the person is just running two block producers on the same network (e.g. two docker containers on the same machine or different machines).

[garethtdavies]

Worth pointing out that the constants detailed here https://github.com/MinaProtocol/mina/tree/compatible/src/app/delegation_backend#constants limit via IP, though not clear what that limit will be.

[GistKen]

Agreed.

For REQUESTS_PER_IP_HOURLY, I would've assumed it accepted X number of requests per hour regardless of the peer id or block producer key (e.g. base58check-encoded submitter's public key).

It brings up an interesting scenario that may be unintentional.
Let's say for example that you are running 3 nodes all on the same network with the same BP key. If we assume that the snarked uptime tracker sends an update once every 5 minutes, that'd be a total of 36 submissions per hour for that IP. If they make the assumption that each IP address realistically would only be sending 1 submission every 5 minutes (aka 1 node on that IP address) and set the max limit to 12, you'd fill that quota in 20 minutes. Therefore, that BP wouldn't be able to get past 33% uptime (assuming they don't correct the configuration).

The same type of a scenario could also apply for the REQUESTS_PER_PK_HOURLY...

[garethtdavies]

Yeh agreed, it's also not clear to me how this will work as most run multiple producers to add redundancy but you then might use up your quota on the one that isn't synced, yet the other two are. Seems you might be better off limiting by peer id? Again though, it's hard to comment without knowing what these constants are to be set at - at present the uptime system sends once every 15 mins