We propose building TAS (Trusta Attestation Service) for building the verifiable identity layer for AI+Crypto ecosystem. In the whitepaper, we introduce the key concepts related to TAS, depict architecture of TAS, and demonstrate its feasibility.
TAS (Trusta Attestation Service) is a public attestation registry built on blockchain. It functions as a decentralized identifier (DID) attestation public good. Similar to EAS 【4】 on Ethereum and Verax on LINEA 【5】, TAS serves as a simple primitive that allows any dApps and protocols to access a shared "data lake" of public data.
Attestation simply means proof or evidence of something. It is usually the statement made by an attestation issuer, or called attestor about something specific. For example, a passport is an attestation of a person’s citizenship, or a degree is an attestation of someone’s educational credentials. In the world of web3, attestations can prove digital identity, ownership of digital assets, trust with a wallet or a primitive etc. For examples,
Owner of 7spRs48WB1aZKSckoVLbixigFgw1cZYSFKMrkjPzySJb is a human being;
Owner of Fu57hTKTr7kd34XFkj9yRC4W23gxVjJNbB8CBq1s4py is a Solana smart contract deployer
Owner of 3rUU4nHk7XGk7ZiBRhGj9fteSzwdJDYpzD1EyMAzb3HH has been KYCed by binance.
TAS is designed to be extensible and modular, and adaptable to a wide range of use cases. Therefore, we need the modules contained in the diagram of "The Design Architecture of TAS", which can help us describe and understand the entire architecture.
Portal & Portal Registry: Portals are smart contracts that are registered in the "Portal Registry" and that you can consider as the entry point to the TAS Attestation Registry. All attestations are made through portals. Specifically, a portal executes specific verification logic through a chain of modules that attestations run through before being issued to the registry. A portal is normally associated with a specific issuer, who would create a portal specifically to issue their attestations with, but portals can also be open to allow anyone to use. There are two ways of creating a Portal: use a default Portal or create your own custom Portal.
All portals must be registered in the Portal Registry.
Schema & Schema Registery: A schema serves as a blueprint for an attestation, outlining the different fields it includes and their respective data types. Anyone can create a schema within the registry, and once established, these schemas are available for reuse by others. For instance, to create attestations that represent a person, we might define a schema like this: (string username, string teamName, uint16 points, bool active). This defines a schema encompassing four fields.
Schemas are stored in the schema registry as a string value that describes the various fields.
Module & Module Registry: Modules are smart contracts that inherit the AbstractModule contract and are registered in the Module registry. They allow for attestation creators to run custom logic to do things like:
verify that attestations conform to some business logic
verify a signature or a zk-snark
perform other actions like transferring some tokens or minting an NFT
recursively create another attestation
Modules are specified in a portal and all attestations created by that portal are routed through the specified modules. Modules can also be chained together into discrete pieces of specific functionality.
Attestation & Attestation Registry: Attestations are created through "portals" that make sure the attestations are consistent with the logic of a specific domain. Attestations are created following "schemas", which describe the structure of the attestation data, i.e. the various fields and their respective data types.
Suppose dApps (such as TrustGo) have already deployed their own portal contract for issuing attestations, specifically the MEDIA reputation attestation. Here are the steps for a user to apply for and receive the attestation:
The user checks their MEDIA score on the TrustGo website.
The user submits a request for the attestation, prompting the TrustGo backend to generate and sign the attestation data.
The TrustGo frontend triggers the wallet to call the portal contract.
The portal contract verifies the data signature and issues the attestation.
Through a suite of smart contracts, the TAS will enable any issuer to provide attestations to Solana accounts. Specifically, the Trusta AI model will issue two types of attestations, similar to what is done in EVM: (1) Media Reputation Attestation and (2) Proof of Humanity (POH) Attestation. For instance, the Media Reputation Attestation schema includes the Solana chain ID and the account's Media score.
Even as a simple primitive, TAS can enable a wide range of use cases, including:
Sybil resistance can be demonstrated through various methods, including iris recognition, on-chain data analysis, and off-chain verifications. It is widely acknowledged that a combination of these approaches is necessary to create a robust solution. TAS offers a platform for testing all these Sybil resistance methods on a wallet and sharing the results with the public.
Example: Account7NUhkMA2…
POH Score = 0.2 --> then it can be given the airdrop eligibility.
TAS facilitates the development of strong, transparent, and continuously evolving reputation scores. These reputations create a marketplace for undercollateralized peer-to-peer lending in the cryptocurrency space.
By utilizing user profiles derived from attestations, service providers can gain a deeper understanding of their users. As a result, they can develop a robust recommendation engine that helps individuals discover new content and dApps tailored to their interests, eliminating the need for a centralized curator.