Project idea: Composite Attestations Engine (CATTS)

Developers
1

I am considering starting another project around attestations, the Composite Attestations Engine (CATTS). I am curious to hear any and all feedback on the idea and draft architecture so far, see link to full article below.

Composite attestations are a new type of attestation combining data from multiple sources to form a unified and verifiable credential.

The Ethereum Attestation Service (EAS) is an infrastructure public good for making attestations onchain or offchain about anything. Attestations can represent identity, reputation, knowledge, and much more. EAS is a tokenless and free service that is available on mainnet, several L2s, and various testnets. EAS is a great service! It is tokenless and free for anyone to use. This means it is being used. A lot!

There is a universe of attestation data out there. EAS provides an API that allows you to query that data which makes integration into websites and apps easy.

2667Ă—1499 162 KB

Let’s say I, as an app, want to offer membership to users that meet certain criteria. I my backend, I can use the EAS API to query all attestations that are relevant to my use case. Then, I write some custom logic to process the data and let the outcome of that logic determine if a user is eligible for membership. Easy!

But, what if I need to show a proof of the outcome of my logic? What if I need to create an attestation that says “This user is eligible for membership”? I can of course easily create that attestation. But, without knowledge of the data I processed or about the processing logic I ran on the data, how can anyone verify that the attestation I created is correct?

Wouldn’t it be great if there was a way to create attestations based on the result of custom queries and processing logic and have the result of that logic be independently verifiable? That’s where CATTS, the Composite Attestations Engine comes in.

2667Ă—1499 252 KB

CATTS allows for the creation of composite attestations based on custom queries and processing logic. Running on the Internet Computer (ICP) as a smart contract canister, it leverages data from existing attestations via the EAS GraphQL API, ensuring that the creation and verification of attestations are both reliable and transparent. The processing logic is defined as a piece of arbitrary JavaScript code, which is executed securely within the canister environment. The engine also provides a receipt for each run, detailing the settings used, which aids in verifying the correctness of the composite attestations.

See more details in below article :point_down::point_down::point_down:

1 Like
2

Bringing a topic from another thread in here.

@skilesare What you heard on the GreenPill podcast I would guess was about EAS - the ETH attestation service CATTS would use?

And yes, we do place some trust that the data from the EAS api is correct. Which is not ideal but definitely ok to begin with. Ideally, CATTS would create a full index of the attestation data on ICP by fetching / subscribing to ETH events instead of fetching from the EAS API.

1 Like
3

Thanks for creating the thread!

Looks like you can validate an attestation and get an attestation as reads. I don’t know if it improves security enough, but you could use different(or even multiple) RPC end points using the new RPC canister and call the functions directly.

Maybe EAS is already doing this for you?

Very cool stuff.

One thing I don’t understand is the off chain attestations. It looks like the scanner has a bunch of off chain attestations. How did they get them? Where are they stored?

4

Overall, I like the idea a lot! I think bringing attestations to ICP has a lot of potential, specifically for combining multiple attestation services on different chains. I am not a big fan of EAS becoming the default attesting service.

A few questions:

  1. Are simulated runs on-chain? I am under the impression that they do not need to be.

  2. How would you verify the recipe that was used to create the attestation?

  3. Do you have a canister architecture map? Is the CATTS canister doing all of the processing and storing of composite attestations?

5

Yep. In the case of CATTS though, you will mostly want to work on many attestations at a time. For that we need to use the EAS API. The risk is the same in all oracle like scenarios, if the source of your data is corrupted, then you are also corrupted. Ways around this:

  1. Like I described earlier, build an ICP EAS indexer with a GraphQL that matches the web2 version
  2. Query more than one instance of the EAS API. The indexer service is open source. If one indexer is run by EAS, one by the CATTS project, and one by… someone else, then security increases drastically.

Off chain attestations are stored mostly on IPFS. I haven’t looked at them in detail but I believe they are referenced with a hash from the attestation. Which means the data can be stored anywhere. Storing offchain attestations on your local drive makes them secret attestations. When asked, you can selectively share the attestation data. The consumer of the data then can compare what you share with the hash to know if is the right data.

6

No, they would be run in the users browser. Developing a CATTS recipe would consist of an iterative … trying a query… coding the processor… simulating… start over

To be determined. An API for that would be nice I guess. So that a service relying on CATTS could easily call an endpoint to verify the correctness of attestations.

Step 1 one would be to verify the run receipt. As it is created by CATTS, it can be trusted.
Step 2 would be to look up the recipe used to create the attestation and rerun the processor on the data. I believe that will seldom be necessary.

Nope, too early for that. :grinning: