Ceramic & Ethereum Attestation Service: How to Use and Store Composable Attestations
Learn about attestations and check out our new tutorial for storing off-chain attestations using EAS.
The Ethereum Attestation Service (EAS) and Ceramic are excited to share an integration that allows developers to easily store EAS attestations on Ceramic. We’ve seen a marked increase in awareness and interest in using attestations to express flexibly-defined, verifiable data about online activity. Attestations are a building block for creating and working with this data.
EAS is an open-source, permissionless, and token-free public good for making on-chain or off-chain attestations. It runs on two elegantly simple smart contracts, one for registering schemas and one for making attestations on those schemas. Developers can use EAS to create, issue, and manage attestations with options to store on-chain, off-chain, and now, on Ceramic.
Ceramic is a decentralized data network for managing data at scale and with trust, making it easy for developers to build applications that rely on verifiable data. It can be used to store a wide variety of data types, including profiles, badges, credentials, attestations, and stamps.
EAS + Ceramic: How to Use and Store Composable Attestations
Attestations play a crucial role in building trust and ensuring data accuracy in various decentralized applications and platforms. EAS offers a straightforward standard that simply works, agnostic of the nature of the attestations themselves or where they are stored. As such, it’s important for communities that rely on attestations to consider the benefits and trade-offs relevant to the attestation frameworks they use, which technical standards those frameworks rely on, and how to safely and efficiently store them for later use.
This blog post will explore the advantages of storing attestations on Ceramic and includes references to a new tutorial for storing off-chain attestations using EAS.
Understanding Attestations
Before diving into Ceramic and EAS, let's briefly recap what attestations are and the key differences between on-chain and off-chain attestations.
Attestations are like digital seals of approval, signed by one entity (the attester) about another entity or a piece of data. The attester cryptographically signs the attestation to ensure its authenticity and immutability. Attestations are basically reputation primitives and therefore only matter based on the context it’s being represented in and the reputation of the attester. For example, a credit score attestation from a credit bureau is more credible than a credit score attestation from a friend. But it’s only relevant if you need to provide a sense of your financial stability. Our friends at EAS go into greater detail on attestation examples here.
Attestations enable the verification and validation of information. When viewed in aggregate, attestations provide an integral building block to the broader manifestation of identity and contextual reputation.
On-chain attestations are stored directly on the Ethereum blockchain, which makes them secure, decentralized and immutable. They are ideal for scenarios where attestations need to be read by smart contracts or when guaranteed availability is essential. On the other hand, if privacy, high-volume throughput, or cost efficiency are important to your need for attestations, then purely on-chain attestations might not be the best option for your use case.
Off-chain attestations are stored off the Ethereum blockchain, often in decentralized storage solutions like IPFS or even in ephemeral cold storage. They are linked to the blockchain through cryptographic signatures but do not reside on it. This makes them great for maintaining attestations privately and sharing them when necessary.
However, some use cases may require the scalability and efficiencies related to off-chain attestations together with the myriad of qualities corresponding to on-chain guarantees. To help meet these needs, there are solutions that don’t fall cleanly into the on vs. off-chain binary, but instead share qualities of both—granting benefits like better scalability with on-chain assurances.
Ceramic, with its unique approach to storing data, serves as an attractive third option for projects seeking a combination of both on-chain and off-chain characteristics.
Ceramic Acts as a Data Ledger
Ceramic can be understood as a middle ground between on-chain and off-chain attestations. It offers a decentralized data network that combines the security and transparency of on-chain transactions with the scalability and cost efficiency typically associated with off-chain solutions.
Ceramic’s underlying protocol is built on decentralized event streams. Users can benefit from a variety of verifiable DID methods (including using their existing digital wallet to incur a did:pkh instance with no additional configuration) to cryptographically sign data events and submit them to the network. Ceramic stores these events in the Interplanetary File System (IPFS), using the IPLD protocol to organize them into readable streams. This flexibility allows developers the ability to store any data types one could expect to find in a traditional SQL/NoSQL database (along with several additional scalars to support decentralized identifiers and account types) needed to create rich user experiences—including attestations, which can be used to reflect users’ experience and reputation on Ceramic.
Ceramic, together with the tools built on the network, provides data-streaming and querying capabilities familiar to developers experienced with tools like Kafka, GraphQL, and relational databases. However, it is built on a fully decentralized and open-source protocol, using the IPLD content addressing protocol within IPFS, which is periodically anchored to the Ethereum blockchain in the form of a Merkle tree. This architecture preserves global consensus, immutability, and transparency while delivering faster performance, lower costs, and straightforward traversal capabilities, making it an attractive option for projects dealing with high volumes of attestations.
Developers can also take advantage of ComposeDB, a graph database built on Ceramic. ComposeDB enhances composability and ease of querying, offering native support for GraphQL and optimizing read/write load distribution for improved performance. This allows developers to define their own data models using GraphQL or leverage existing community-defined models.
Create Your Attestations
Follow along in this tutorial to learn how to generate simple off-chain attestations representing a “met in real life” claim. This guide uses a preexisting attestation schema already deployed on the EAS schema registry and therefore is designed to focus on the core processes and attributes available to developers using the EAS SDK.
You will learn how to generate off-chain “met in real life” attestations, allow users to generate referenced attestations confirming the original attestation, and verify attestations instances—all within the context of using ComposeDB to store and query attestations.