Sismo Docs
Search…
⌃K
Links

Attesters

Attesters are core smart contracts of the Sismo protocol. They are in charge of verifying user requests and issuing attestations. Example implementations can be found in the Attesters Examples section.
Attesters

Available Groups

A group is said to be available for an attester when the attester has access to on-chain data in the specific format that it requires. This enables the attester to validate user claims. Most attesters require a third party to post on-chain data (e.g merkle roots), though some just read from the EVM directly. Each available group has a group identifier so it can be targeted by user claims.

User Request

A Claim, in the context of a specific attester has three fields:
  • groupId: uint256 - a targeted group from a list of groups available to the attester
  • claimedValue: uint256 - a claimed value to be compared to the actual account value that the user owns in a targeted group
  • extraData: bytes - optional arbitrary data that might be required and verified by the attester
A Request, targeting a specific attester, is defined by:
  • claims: Claim[] - a set of user claims to be verified by the attester
  • destination: address - the address that will receive the attestations
For a user request to be validated by an attester, users must provide a proof so that the attester can verify each claim.
The user sends the request (alongside its proof) to the attester by calling the generateAttestations(request, proof)standard function of the attester contract.

verifyRequest (internal standard function)

When the attester receives a user request, it first verifies whether the proof confirms the user's claim(s).
This is the most important function of an attester.
The standard internal function verifyRequest(request, proof) of an attester takes the user request and its proof as arguments and throws if they are not valid.
While some attesters will simply perform checks (such as NFT/ERC20 balance check), others will do more complex proof verifications such as verifying a merkle proof or verifying a Zero-Knowedge Proof (ZKP).
At Sismo we focus first on ZK Attesters, which are privacy-preserving attesters.
Here, users provide proofs that do not reveal which accounts were used to confirm their claims.
In the verifyRequest function of our ZK Attesters, ZKP are verified.
We invite developers to create innovative request verifications and issue creative attestations! As you'll see, the standard provides a lot of freedom for developers.

buildAttestations (internal standard function)

Once a request has been verified, the attester must build the attestations that will be recorded in the Attestation Registry.
The internal function buildAttestations(request, proof)of an attester is its second most important function.
This function takes the verified user request (its claims and destination) as input, and outputs the attestations that will be issued.
The built attestations are then recorded in the Attestation Registry.

generateAttestations (external standard function)

// This is the external function standard to all attesters
// This function is called by end users
function generateAttestations(Request calldata request, bytes calldata proofData)
external
override
returns (Attestation[] memory)
{
// To be implemented by attesters devs
// Verify if request is valid by verifying against proof
_verifyRequest(request, proofData);
// To be implemented by attesters devs
// Generate the actual attestations from user request
Attestation[] memory attestations = buildAttestations(request, proofData);
// hook
_beforeRecordAttestations(request, proofData);
ATTESTATIONS_REGISTRY.recordAttestations(attestations);
// hook
_afterRecordAttestations(attestations);
for (uint256 i = 0; i < attestations.length; i++) {
emit AttestationGenerated(attestations[i]);
}
return attestations;
}
Head over to the examples section to see different implementations of attesters.
We built the Sismo Protocol with modularity as top priority. Anyone is invited to propose new attesters by forking and tweaking existing ones, or by creating entirely new attesters!