EAS, the Base Layer for Attestations

Key Takeaways

• If personal information can be managed by the providers themselves and holistically organized through a common interface that can be utilized across different platforms, we can dream of a wide range of interactions in the digital space as well as in the real world and beyond.

• Ethereum Attestation Service (EAS) is an open infrastructure that can contribute to bridging the gap between the real world and the web3 by standardizing the attestation of all kinds of tangible and intangible assets and interactions.

• However, there are several improvements to EAS, including trust issues with attestors, gas costs for continuous on-chain attestation needs, and EVM dependency.

1. For Broader Digital Interactions

Before we interact with someone, we collect a lot of information about them and aggregate it to determine the scope and depth of the interaction. The information that is collected includes most of the information that can be observed in our daily lives - often ranging from explicit information such as demographics, financial transactions, and online social activity to subjective information such as first impressions or reputation.

In the real world, rather thanks to physical constraints, it is often possible to collect comprehensive data from a broad spectrum of individuals. Therefore, each individual can have a wide range of deep interactions with the environment in which they have spent most of their time.

In the real world, rather thanks to physical constraints, it is often possible to collect a wide range of such information from a limited set of people. The digital world, on the other hand, although it has the advantage of being largely free of physical constraints, is quite limited in the range and depth of interactions that can take place compared to the real world - recently, digital credentials, DIDs, and other technologies that can prove identity or various activities have been actively researched in the digital context. However, these technologies are still being utilized in limited areas and do not seem to be scalable enough to accommodate a significant range of interactions.

There are many reasons for this, but fundamentally it comes down to how the data is managed. Most data is managed on centralized servers or as a monopoly by a handful of platforms, so individuals are limited in their ability to freely reorganize and use their data across platforms, even though they are the data providers. In addition, the way each data is organized by platforms is also different rather than following a single standard, so it is difficult for such fragmented data to be integrated and practically utilized on multiple platforms.

In short, if personal information can be managed by the providers themselves and holistically organized through a common interface that can be utilized across different platforms, we can dream of a wide range of interactions in the digital space as well as in the real world and beyond.

2. Different Attestation Solutions Based on Blockchain

Blockchain ensures that all data is open and can be utilized by anyone in a trusted manner. As such, we expect to revolutionize the way personal data is handled in the traditional digital space as we can transfer a variety of values over a trust-based network without relying on a centralized entity.

Currently, a variety of solutions are emerging in the blockchain ecosystem to strengthen an individual's identity or to store and represent attestation of various activities.

Reputation Credentials

Source : Towards More Identifiable Worlds with Web3 Reputation

The most active class of solutions is the Web3 Reputation Credentials project. Following the structure of the existing W3C’s Verified Credential Specification, these projects reorganize the way identity and reputation are attested in a centralized and inefficient way, with a blockchain at its core. With this approach, anyone can create their own contextualized credentials with low trust costs and marginal production costs.

Currently, there are many projects in the blockchain ecosystem that leverage the above structure* to allow users or projects to create and utilize their own identity information/credentials in various contexts (e.g., marketing, quests, education, recruitment, credit scoring, KYC, etc.).

Source : Towards More Identifiable Worlds with Web3 Reputation

However, since the structure is more of an abstract blueprint than a clear interface, the credentials implemented by different projects are not compatible with each other, and there is a need for a mechanism to curate such many different credentials already deployed.

*Not all solutions follow the above structure exactly - in particular, Gitcoin Passport is a schema created via EAS, which will be discussed in this article later.

Social Profile & ENS & SBT

NFTs have been utilized as a representative means of signaling the authenticity of certain assets. As a result, we have observed several attempts to expand their use by adding various attributes to the basic NFT structure to form identity accounts (e.g., Lens Profile, ENS, etc.) or issue certificates for specific activities (e.g., SBT Badges).

However, basically, the limitations of the NFT standard-derived concepts are relatively clear, including 1) their metadata must be outsourced to an external registry, which limits the format and amount of data to be attached, and 2) it is quite difficult to insert various functions (such as social recovery, especially for NFT-based identities) into it.

Moreover, in the case of ENS, it is necessary to continuously pay a fee at regular periods to maintain its ownership, and in the case of SBT, it is useful for recording an individual's affiliation, activity history, qualifications, etc. to emphasize their position in the community, but there is a risk that the account itself holding it may be transferred or lost.

In short, NFT-based identity/attestation solutions are neither scalable in terms of representing data, nor do they have clear structural limitations in terms of management.

Universal Profile

Source : LSP0(ERC725 Account)

Universal Profile is a 'smart contract-based identity account' that extends ERC725 - the main idea of ERC725 is to define identity accounts through the concept of a generic executor called ‘ERC725X’ and a universally accessible key-value based repository called ‘ERC725Y’. Universal profiles allow users to perform a wide range of functions that are not possible through traditional EOAs (i.e., smart contracts can do this), and the profiles can store, reference, and update data in a flexible and format-agnostic manner.

An example of a project that has been actively utilizing universal profiles is LUKSO. LUKSO is building a UX-friendly mainnet by proposing its own set of standards (LSP, LUKSO Standards Proposals) to organize universal profiles as basic identity accounts and to ensure that the way these accounts interact within the ecosystem is flexible and extensible. Moreover, since LUKSO can be integrated with various EVM chains by forking the architecture of Ethereum, it is highly anticipated that various applications will emerge that allow users to enjoy a platform-agnostic experience within the EVM ecosystem.

However, despite the fact that an unlimited range of activities can be recorded within an identity account (i.e., a universal profile), there is still a lack of an Attestation standard framework within LUKSO that labels and externally attests to these activities.

And EAS

In short, all of the above solutions are highly promising from a specific use case viewpoint, but they are limited in their ability to holistically represent diverse data or lack a common interface that can be built upon. In other words, from the user's perspective, it still does not solve the issue of fragmented management of individual information.

Source : EAS Docs

In response, Ethereum Attestation Service (EAS) presents a single, abstracted Attestation* standard framework that unifies fragmented identities, credentials, reputations, etc. defined at the application level and underlies all interactions. As its name implies, EAS is an infrastructure tool built for the purpose of attesting to something in any EVM supported on-chain or off-chain environment.

As a public good, EAS is a digital signature scheme that is completely open source and free for anyone to create and verify structured Attestations. Users only need to define a data schema and create an Attestation with that schema to attest any subject.

Currently, EAS is deployed on Ethereum mainnet, as well as various L2 solutions (e.g., Arbitrum, Optimism, Base, Linea) and testnet environments (e.g., Sepolia, Base Goerli, Optimism Goerli, Arbitrum Goerli, Polygon Mumbai, Linea Goerli) that support EVM, with nearly 130k+** Attestations published as of November 29, 2023.

*In fact, the term Attestation is often used to refer to an exchange between nodes in a consensus algorithm to validate a block or certain piece of information.

**More than 100k+ of the approximately 130k+ attestations were posted by Optimism, with the majority coming from Gitcoin Passport.

3. Overview of EAS

There are two core contracts for EAS - SchemaRegistry.sol & EAS.sol

3.1 Defining the Attestation Structure - SchemaRegistry.sol

First, the SchemaRegistry contract is a schema contract that defines the data structure of the Attestation, that is, a data frame that customizes the purpose, content, and context of what the Attestation is trying to attest to.

Source : EASScan - Optimism

These schemas are easy for anyone to create or experiment with, and see what other schemas are out there. DApp / platform developers can utilize SDKs or interact directly with smart contracts, and even non-coders can easily create and verify schemes via EASScan - protocols currently supporting EASScan include Ethereum Mainnet, Optimism, Base, and Arbitrum, and testing is available on Sepolia, Optimism Goerli, and Base Goerli.

Source : SchemaRegistry.sol

Having drawn the structure of the schema in the brain, it can be registered in the registry of the SchemaRegistry contract via 'register' method. At this point, the schema's UID (unique identifier) is automatically assigned and stored in the registry. In addition to UID and Schema, other variables that can be set are Resolver and Revocable.

Resolver

• Resolver is a smart contract that acts as a hook to the Schema.

• In simple terms, it is a step that pre-checks whether an Attestation conforms to certain rules or logic defined by the Attestor before it is actually issued.

• For example, an Attestation can be restricted to a certain group of users or to users who meet certain conditions - examples of various reference implementations can be found at this link.

• However, since Resolver is an external smart contract, it remains unclear whether or not it is secure, and those wishing to utilize it should do so at their own risk.

Revocable

• Revocable is a variable that indicates whether the schema can be revoked at a later date.

• This allows for flexibility in the event that an Attestation is no longer valid, or if it was issued incorrectly in the first place and needs to be corrected.

• If an Attestation, whether created on-chain or off-chain, was originally created with Revocable set to YES, it will later become invalid by simply changing the value of the revoked field in the Attestation to True - this can be easily set in EASScan or by interacting directly with the SDK or smart contract.

3.2 Attestation Building and Management - EAS.sol

EAS.sol is a contract that utilizes schemas registered through SchemaRegistry.sol to create and revoke attestations in practice.

Source : Common.sol

In addition to UID and Schema, there are 8 field values that make up an Attestation,

Time

• This variable is a field that records when the Attestation was created in the form of a Unix timestamp.

• However, if the attestation is made off-chain, the timestamp is not supported, in which case the SDK can be utilized to timestamp the UID to store it on-chain.

ExpirationTime

• If set by the Attester, this variable indicates when the Attestation will expire.

RevocationTime

• If Revokable option is activated, this variable indicates when the Attestation is revoked.

refUID

• This variable is included to provide a richer, more configurable context for the Attestation by referencing the UID of other Attestations.

• For example - if each transaction of a particular asset leaves an Attestation and references all previous transactions, the transaction history of that asset can be transparently tracked. Alternatively, to manage a particular event and its sub-event separately, a hierarchical set of Attestations can be configured by having the sub-event Attestation reference the parent event Attestation.

Recipient

• Ethereum address of the recipient of the Attestation.

Attester

• Ethereum address of the person who created the Attestation.

Revocable

• Bool variable indicating whether the Attestation is revocable.

Data

• The data that the Attestation is encoded in.

Source : EASScan - Optimism

For better understanding, here is an example of an Attestation from Gitcoin Passport Score* deployed on-chain via Optimism EAS.

*Gitcoin Passport Score is a Humanity Score that allows users to prove that they are indeed human in order for Gitcoin to manage its donation policy more transparently and fairly.

1. UID - The UID of this Attestation.

2. Time & ExpirationTime & Revokable & RevocationTime - Indicates when the Attestation was created, when it expires (if it expires), and whether it is revoked (if it is revocable).

3. Schema - Indicates which schema structure the attestation follows. This Attestation follows the Gitcoin Passport Score V1 scema.

4. Attester & Recipient - Indicates from whom and to whom the attestation was issued.

5. Schema Data - Decodes the Attestation Data based on the schema utilized in the Attestation.

6. Transaction ID & Reference - Displays the Transaction ID and Reference information of the Attestation. In this case, it does not reference any other Attestation.

3.3 Attestation Storage - On-chain & Off-chain

Source : EASScan - Sepolia

Finally, while completing the digital signature for the Attestation, users can choose whether the information is stored on-chain or off-chain. Note that storing an Attestation on-chain requires a small amount of gas, while storing it off-chain does not.

Source : EASScan - Sepolia

Once an Attestation is created on-chain, it can be scanned by anyone through EASScan

Source : EASScan - Sepolia

However, if the Attestation is created off-chain, it cannot be detected by EASScan.

The above is an example of deploying an Attestation off-chain in Sepolia testnet environment with a scheme called MAKE A STATEMENT. Because it's deployed off-chain, the Attestation is labeled as Private, and EAS provides various ways to share it, such as downloading it or providing a browser URL link, as shown on the right*.

Off-chain Attestations can be published on IPFS as shown above, or published on Ceramic Network, a decentralized storage solution via SDK - if published on Ceramic Network, they are leveraged with GraphQL-based ComposeDB, allowing developers to stream and query data against the Attestations in a traditional and familiar way.

*Utilizing the Tools tab in EASScan, multiple off-chain attestations can be verified and timestamped at once.

3.4 Gimmicks to Ensure Privacy

On the one hand, the transparency of blockchain data being publicly available has always been considered a double-edged sword, as it allows an individual's activities to be monitored. As a result, there has been an active effort to incorporate privacy solutions on-chain so that an individual's activities are validated by the blockchain, but the details are not disclosed.

In this context, EAS may also need to record sensitive information in some cases, so it is important to pay attention to gimmicks that can ensure the confidentiality of the data.

3.4.1 Utilizing Off-chain Attestations

The most intuitive and straightforward approach is to publish the attestation off-chain, as discussed earlier - the attestation can be managed with a browser-based URI or shared by utilizing a file format. The computation to verify the original data is done externally, but only the result is proved on-chain, so third parties do not have access to the details of the attestation on-chain. However, even in this case, there is a drawback that separate efforts are required to manage the attestation link or file.

3.4.2 Utilizing PRIVATE DATA Schema

Source : coinmonks

The second method is to utilize the Merkle tree structure - a Merkle tree hashes the entire data in small pieces, recursively hashes the hash values, and finally generates a single Merkle proof to prove the original data. The advantage of this is that the entire data can be represented as a single encrypted proof without disclosing it, allowing data to be published in a secure and scalable way.

Source : ENSScan - Sepolia

Fortunately, a reference schema for MerkleTree (i.e., PRIVATE DATA) has already been built utilizing OpenZeppelin's Merkle-tree library and ethers.js, and is currently available on the Ethereum Mainnet, Arbitrum, and Sepolia. Users can input source data into this schema and publish an Attestation for a specific activity based on the returned Merkletree root value.

3.4.3 Leveraging Privacy Solutions

Another option is to utilize privacy solutions themselves, such as zero-knowledge proofs or homomorphic cryptography.

Zero-knowledge proofs can be utilized to prove to another party that a particular statement is true without disclosing any details - for example, attestations generated by EAS can be wrapped once more in a zero-knowledge proof before being sent to a potential recipient, allowing the attester to hide the details of the information they are sending.

Source : Scout Article (October, 2023)

Alternatively, it is possible to apply homomorphic cryptography, which the blockchain industry has been actively trying to adopt recently. Homomorphic cryptography is a solution that computes encrypted data and outputs interpretable results without having to decrypt it first. This eliminates the possibility of data leakage because the data is always kept confidential from the time it enters to the time it leaves.

4. Potentials and Limitations of EAS

The interactions and attestations of practically "all kinds" of tangible and intangible assets across the real world and the web3 - including identity, credentials, oracles, social data, authenticity of real-world assets, supply chain trace, etc. - could theoretically be supported by EAS, depending on how its structure is defined. In other words, it's not an exaggeration to say that most of the use cases we can imagine for blockchain can be accomplished through EAS.

As such, EAS is essentially an abstraction layer that allows for various ways to redefine the raw data of a blockchain network - the biggest advantage of EAS is its extreme flexibility and scalability. Moreover, the structure of EAS is extremely simple, and non-developers who are not familiar with code can easily design schemas and create attestations via EASScan, making its utilization even more promising.

However, there are some concerns that come with the promise of its versatility. First of all, there is still the issue of trust for the Attestor issuing the Attestation. EAS provides trust in a set of processes that ensure the integrity of the data, but does not address the trustworthiness of the Attestor itself. As a result, when users want to reference a substantial number of Attestations, they may need to put in extra effort to curate and sort through them all by referencing other information.

Additionally, publishing attestations on-chain via an EAS can cost a lot of gas. Of course, EAS supports batch processing, so it's possible to publish multiple attestations at once, but it's probably not ideal for use cases that require continuous and repetitive attestations - as shown in the stats above, gas costs are probably a large part of the reason why Optimism and Base publish so many attestations compared to other mainnets.

Finally, EAS is highly dependent on EVMs, so it has the limitation of only ensuring interoperability within the EVM ecosystem. Currently, in addition to EVM, various VMs such as WasmVM, MoveVM, and SVM are gaining share in the blockchain ecosystem. Of course, it would be fine if the blockchains using those VMs made themselves EVM-compatible, but if they don't and the share of EVMs decreases, the attraction of EAS would not be much higher.

Thanks to Kate for designing the graphics for this article.