Hi @seref , thanks for connecting and introducing us to Index Network, it’s a super interesting project and we’re delighted to be collaborating on it! Here is the response to questionnaire you linked to on your post. h/t to @alain_ncls and Arthur for crafting these responses (I had nothing to do with it, just posting them here).
Verax for Large Language Model Interactions
This document serves as a guideline for framing scenarios involving interactions with Verax and a large language model from a user perspective. It aims to provide a simple understanding for the discoverability of Verax, interaction with algorithms, and understanding the approaches to ownership, privacy, and collaboration.
Describe Verax to a Large Language Model from the User Perspective:
How does the user interact with the large language model? What types of queries can the user submit? How does the model process and respond to these queries?
From a user perspective, interaction with Verax and a large language model can be described as follows:
The user interacts with the large language model by submitting queries or requests in the form of text. These queries can range from simple factual questions, complex research inquiries, to technical problem-solving. The model processes these queries by understanding the context, intent, and specific requirements of the user’s request. It then generates a response that aims to fulfill the user’s request to the best of its ability.
Verax Overview: Verax is a shared, public attestation registry that can be deployed to EVM chains. It serves as a platform for dApps to store data of public interest, also known as “attestations”. These attestations are statements made by an attestation issuer about something specific and can be easily accessed and composed together by anyone interested.
Types of Attestations: Attestations can include various types of claims or credentials. For example, they could attest that the owner of a specific address has completed a course on Solidity, or that a contract at a particular address is a malicious ERC-20 token. They could also verify that the owner of an address is a human being (i.e., not a bot), or a member of a specific DAO.
Usage of Verax: Verax can be used by issuers of attestations, consumers of attestations, and reputation protocols. Issuers can choose to issue their attestations to an existing Verax instance on a network, making their attestation data widely discoverable and easily consumed. Consumers can compose attestations from multiple sources, allowing users to prove they are not a bot without being tied to a specific provider. Reputation protocols can leverage linked data and shared ontologies to create rich and powerful semantic graphs, providing users with valuable insights and information.
In summary, Verax provides a platform for the issuance, discovery, and consumption of attestations, facilitating a more transparent and collaborative ecosystem. The large language model aids in this process by providing intelligent and context-aware responses to user queries related to Verax and its functionalities, but also to Verax already issued attestations, published Portals, Modules and Schemas. It helps users understand and navigate the Verax ecosystem, thereby enhancing their interaction and experience.
The model needs to classify the questions in various categories:
- Technical questions: by picking from example projects and from the official documentation (https://docs.ver.ax), the model helps a developer onboard the Verax platform, create his first Portal and Module, register those, etc. It also tackles questions around the Verax SDK (how to instantiate it, fetch attestations, interact with the contracts, etc.), the Verax subgraph (how to build complex queries, etc.).
- Discovery questions: list the Portals, the already registered Schemas, build queries from natural language questions, etc.
- Ecosystem discovery: list the issuers, the tools using Verax, the tools built by the Verax team (Snap, Explorer, hackathons, etc.).
What is Verax’s approach to information discovery?
What’s the role of information discovery for Verax?
Verax’s approach to information discovery is multi-faceted and designed to provide a comprehensive and transparent view of the attestations within its ecosystem. Here’s how Verax facilitates information discovery:
- Attestations Issued by Third Parties: Verax allows third-party entities to issue attestations. These attestations serve as a source of information that can be discovered and accessed by anyone interested. They provide valuable insights about specific claims or credentials related to an address, contract, or DAO.
- Explorer: The Verax Explorer is a tool that enables users to navigate through the attestations in the Verax ecosystem. It provides a user-friendly interface for discovering and understanding the attestations issued on the platform.
- API / TheGraph: Verax leverages TheGraph’s GraphQL API, for querying and accessing data. This allows for efficient and flexible information discovery, enabling users to retrieve specific data points based on their requirements.
- On-Chain: All attestations in Verax are stored on-chain. This ensures transparency and immutability, allowing anyone to verify the authenticity of the information. On-chain storage also facilitates information discovery as the data is publicly accessible on the blockchain.
- (Future) Attestation Linking: In the future, Verax plans to link attestations together. This will create a network of interconnected information, enhancing the depth and breadth of information discovery. It will allow users to understand the relationships between different attestations and gain a more holistic view of the information landscape within Verax.
In summary, Verax’s approach to information discovery is designed to be transparent, accessible, and comprehensive. It leverages various tools and strategies to ensure that users can easily discover and understand the attestations within its ecosystem. This approach plays a crucial role in Verax’s mission to facilitate a more open and collaborative attestation ecosystem.
Example user queries in natural language:
Tell me about [Topic/Subject]?
How do I [Task/Action] in [Language/Tool]?
- Does [Ethereum address] have a proof of humanity attestation from [this issuer]?
- Give me all the attestations relative to this Ethereum address [address]?
- How many users have an attestation from [name of the issuer]?
- Give me the list of addresses that received attestations from [issuer]?
- Can you create an attestation for [name] issued to [recipient]?
- How can I create my own attestations?
- Provide a code to build my own portal following [requirements]
Example user actions in natural language:
Create [Output] based on [Input].
- Issue an attestation through the [issuer_name] portal based on the Verifiable Credential stored on [protocol]
- Attest that I trust this smart contract: [address]
- Revoke this attestation [attestation_id]
Capabilities of Verax in composability with other contextual entities
Do you think Verax shines when used in a composable way with other contextual entities or protocols? (hint: intent, reputation, trust, identity, knowledge, and maybe something else.)
Verax stands out in its ability to aggregate and consolidate public data points from a wide array of decentralized applications (dApps) into a single, unified on-chain datastore. This approach significantly mitigates the issue of data fragmentation across the blockchain ecosystem, where each dApp might traditionally rely on its own separate on-chain storage mechanisms. By centralizing data in this manner, Verax facilitates a more streamlined and efficient data management process, enhancing the accessibility and utility of on-chain data.
The consolidation of data within Verax not only simplifies data management but also greatly improves the ease with which data can be indexed and analyzed. This centralized approach enables developers, researchers, and users to more effectively query the blockchain for specific data points, derive valuable insights, and make informed decisions based on a comprehensive view of the data landscape. This capability is particularly beneficial in complex ecosystems where understanding interrelations and patterns across different dApps and transactions is crucial.
A notable challenge can be the heterogeneity of data, where different sources may use varying naming conventions and semantic definitions. Verax addresses this challenge by incorporating a concept borrowed from JSON-LD known as the “context.” Each schema registered within Verax includes a context field in its metadata, which provides a reference (either a URL or an attestation ID) that guides consumers on how to interpret the schema’s fields. This innovative approach facilitates a common understanding of data, enabling seamless composability and interoperability across different sources and applications.
By allowing context fields to point to well-known shared vocabularies, such as those provided by schema.org, Verax ensures that data consumers can easily comprehend the attestations they encounter. This standardization of data interpretation is pivotal in fostering a cohesive ecosystem where entities from diverse backgrounds and applications can interact and collaborate effectively, without the barriers posed by semantic discrepancies.
Verax further enhances its composability through the Portals, which extends compatibility with other standards, such as ERC-721 or EAS. This compatibility ensures that Verax can seamlessly integrate with a wide range of existing protocols and platforms, facilitating a rich ecosystem of interconnected applications and services. By embracing and extending industry standards, Verax positions itself as a versatile and adaptable solution that can cater to a broad spectrum of use cases and requirements within the blockchain domain.
What is Verax’s approach to collaboration?
How does Verax facilitate collaborative efforts between users or between users and AI agents?
By design, Verax fosters collaboration by enabling the storage of data of public interest in an single place, facilitating accessibility, discoverability and readability in a common standard. By making these data freely available on the blockchain, Verax empowers a wide range of users, including developers, researchers, and businesses, to leverage this information for their specific use cases. This open-access model fosters a collaborative environment where shared data resources can be utilized to drive innovation, enhance services, and develop new applications. It democratizes access to information, ensuring that anyone with an interest or need can tap into the wealth of data stored within Verax.
Verax’s infrastructure not only supports individual projects but also facilitates synergies between different initiatives and platforms. A prime example of this is the collaboration between zkPass, issued zero-knowledge proofs of KYC on OKX, which are leveraged by Linea Proof of Humanity and, more recently, the Foxy team for their airdrop. By serving as a foundational layer that supports the issuance and verification of attestations and credentials, Verax enables diverse projects to interoperate and leverage each other’s strengths. This cross-pollination of capabilities enhances the overall ecosystem, allowing projects to build upon each other’s work and offer more comprehensive and sophisticated solutions to users.
By providing a reliable source of verified data, Verax enables AI agents to access and interpret on-chain information accurately, which can be used to automate processes, provide insights, or enhance user experiences. This collaboration between humans and AI opens up new possibilities for innovation, where AI can assist in data analysis, decision-making, and even in the creation of new attestations or credentials based on predefined criteria.
What is Verax’s approach to privacy?
Describe Verax’ privacy structure, especially from the information discovery perspective.
All the data stored on Verax is inherently public. Recognizing the potential privacy concerns, we advocate for the use of zero-knowledge technology when privacy matters
What are the data models, and where are they?
Please explain their roles.
We are curious about your perspective on storing them with their probabilities.
Thanks for guiding the indexers.
In Verax, the data models primarily consist of Attestations, Portals, Modules, and Schemas. These components play crucial roles in the functioning of the Verax ecosystem. They are stored on-chain, ensuring transparency, immutability, and easy discoverability. Let’s delve into each of these components:
-
Attestations: Attestations are statements made by an attestation issuer about something specific. They are recorded in a consolidated location on-chain, making them easily discoverable and consumable.
Attestations have various metadata recorded besides the raw attestation data itself. A description of this metadata is listed in the table below:
| Property |
Datatype |
Description |
| attestationId |
bytes32 |
The unique identifier of the attestation |
| schemaId |
bytes32 |
The identifier of the Schemas | Verax | Verax Documentation this attestation adheres to |
| replacedBy |
uint256 |
The attestation ID that replaces this attestation |
| attester |
address |
The address issuing the attestation to the subject |
| portal |
address |
The address of the Portals | Verax | Verax Documentation that created the attestation |
| attestedDate |
uint64 |
The date the attestation is issued |
| expirationDate |
uint64 |
The expiration date of the attestation |
| revocationDate |
uint64 |
The date when the attestation was revoked |
| version |
uint16 |
Version of the registry when the attestation was created |
| revoked |
bool |
Whether the attestation is Revoke an Attestation | Verax | Verax Documentation or not |
| subject |
bytes |
The ID of the attestee e.g. an EVM address, DID, URL etc. |
| attestationData |
bytes |
The raw attestation data |
-
Portals: Portals are smart contracts owned and controlled by the dApp. They serve as the interface through which dApps interact with Verax. The portal contract performs verification checks or other actions according to the dApp’s business logic and then records an attestation in the registry.
All Portals contain certain metadata associated with them when they are registered:
| Field |
Type |
Description |
| id |
address |
The portal ID (the address of portal contract) |
| ownerAddress |
address |
The address of this portal’s owner |
| modules |
address |
Addresses of modules implemented by the portal |
| isRevocable |
bool |
Whether attestations issued can be revoked |
| name |
string |
(required) A descriptive name for the module |
| description |
string (URI) |
(optionally) A link to documentation about the module, its intended use, etc. |
| ownerName |
string |
The name of this portal’s owner |
-
Modules: Modules are small smart contracts that perform simple verification logic. A portal can chain together these modules, and every new attestation goes through each module in the chain. Each module performs a simple check, and if all modules verify the new attestation successfully, the portal then submits the attestation in the registry.
All Modules contain certain metadata associated with them when they are registered:
| Field |
Type |
Description |
| moduleAddress |
address |
(required) The address of the module smart contract |
| name |
string |
(required) A descriptive name for the module |
| description |
string (URI) |
(optional) A link to documentation about the module, its intended use, etc. |
-
Schemas: Schemas describe the data structure of the attestation data. Every attestation references a schema, which is a description of the properties in an attestation and what their respective data types are. DApps can use any existing schema or create their own.
All Schemas contain certain metadata associated with them when they are registered:
| Property |
Datatype |
Description |
| name |
string |
(required) The name of schema, stored on-chain |
| description |
string |
A link to off-chain description / documentation |
| context |
string |
A link to some shared vocabulary / ontology |
| schema |
string |
(required) The raw schema string as described above |
