Avoid distance computation spam

name: Distance computation spam
about: Distance rule
title: "Avoid distance computation spam"
labels: enhancement
assignees: ""

Motivation

The distance rule requires an expensive computation. Our benchmarks lead to ~1s of computation time on our reference machine (Raspberry PI 4 Model B with an SSD).

A member should not be able to spam membership extrinsic leading to a free distance computation.

See https://forum.duniter.org/t/benchmarks-pallet-membership-et-dependance-a-pallet-certification/11155/9 for more context.

Analysis

As of today, the check_idty_allowed_to_claim_membership function is the place that ends with a distance check, and is only preceded by a control about having enough certifications.

This function is called through 2 extrinsics:

1. validate_identity -> check_validate_identity -> check_allowed_to_claim
2. renew_membership -> check_idty_allowed_to_renew_membership

None of these extrinsics have anti-spam mechanisms other than extrinsic cost, which is refunded (or at least should be) for a member if the extrinsic executes successfully.

However, validate_identity (1) is not idempotent: once called successfully, it cannot be called again as it will raise IdtyNotConfirmedByOwner or IdtyAlreadyValidated (note: add tests about this to ensure this behavior is true for every IdtyStatus). So there is no issue at all with it (success cannot be repeated, failure is paid).

That's not the case for renew_membership which is idempotent.

Suggested Solution

The check_idty_allowed_to_claim_membership must be preceded by a check ensuring a delay has been observed since the last successful validate_identity or renew_membership, and fail otherwise.