Implement Cached Score Retrieval in Gitcoin Passport Smart Contracts

[nutrina]

User Story:

As a passport developer and integrator,
I want a gas-efficient method, like a getCachedScore function within the resolver,
To retrieve the numeric score of a user’s Passport from a cached mapping, thus ensuring minimal gas costs during operations like gating smart contract calls.

Acceptance Criteria

GIVEN I am a developer integrating with the Gitcoin Passport system,
WHEN I call the getCachedScore(address user) function of the GitcoinResolver smart contract,
THEN I expect the cached Score structure for the user's Passport to be returned from a cached mapping within the resolver smart contract,
AND the function should revert the transaction if no score is available for the provided ETH address.

Product & Design Links:

Not applicable.

Tech Details:

• Introduce a cached mapping, such as mapping (address => Score), in the GitcoinResolver smart contract where:

// The following struct should ideally fit into a 32 byte storage slot
struct Score {
  uint32 score;           // considering only 4 decimals should be sufficient
  uint64 issuanceDate;    // For checking the age of the stamp, without loading the attestation
  uint64 expirationDate;  // This makes sense because we want to make sure the stamp is not expired, and also do not want to load the attestation 
  uint32 scorerId;        // would we need this ???
}

• This caching strategy aims to bypass the costlier process of loading entire EAS (Ethereum Attestation Service) attestations.
• Ensure that the cache is updated when attesting & revoking attestations:
  • save the value on the attest hook
  • delete the value on the revoke hook

Open Questions:

Not applicable.

Notes/Assumptions:

• Assumes that the primary goal is to optimize gas costs while maintaining the functionality and reliability of the score retrieval process in smart contracts.
• Assumes that the caching mechanism will align with the existing infrastructure of the Gitcoin Passport system.

[nutrina]

To be discussed further: we could also change the number of digits in the value that we store in the EAS attestations.
This will make any transformation / casting of the value to fie in the score attribute of Score structure specified above easier. (ideally a simple cast suffices).
@lebraat

[nutrina]

Waiting to review this with somebody.

[tim-schultz]

This looks good to me. Imo we should wait on deploying this until #1928 is also deployed it seems like it could introduce some confusion about the score value if not deployed together.

[tim-schultz]

These changes have been merged let us know if we should deploy this before #1928 is completed

[nutrina]

Putting these back in progress as I have found some bugs:

• we don't account for Scores written as part of a multiAttest (have already created a failing test for this)
• we do not delete a cached score when revoking

[nutrina]

The work on these branches has been merged int the branch for #1928