Micro-Rollups' verifiable off-chain computation, auditable state, and on-chain application integration capabilities may drive explosive growth in real-world use cases on the chain.

Author: stackrlabs

Translator: Frank, Foresight News

Attestation, this is a widely understood term, and almost everyone has some understanding of its meaning and has used this concept unconsciously in their lives.

So let's try to define it. Attestation is essentially a statement or declaration made about certain information, provided as evidence or confirmation by a trusted party to verify the truth of a specific statement. The credibility of the attestation depends on the reputation of the entity providing the attestation. In the Web3 world, attestations come with digital signatures to ensure authenticity and immutability.

Let's look at some examples, whether in the real world or in the crypto field, you may not have realized that they are actually some form of attestation.

Attestation in the Web3 world: Ethereum Attestation Service

The Ethereum Attestation Service (EAS) is one of the leading projects in the Web3 field that supports attestation use cases. It is an open-source infrastructure public product used for on-chain or off-chain attestation. The operation of EAS is very simple. You just need to register a schema about any topic (or use an existing schema), and then make attestations based on that schema.

Limitations

Although EAS provides a solid foundation for attestation reasoning and utilization in Web3, it is not without limitations. The cost of on-chain attestation using EAS may be very high, and writing EVM smart contracts is required to implement any custom logic. For off-chain attestation, the schema still needs to be placed on-chain, and developers often store these attestations in private databases, compromising user verifiability.

This highlights how Micro-Rollups built using the Stackr SDK can enhance the functionality of EAS or attestations as a whole.

Quick Introduction to Micro-Rollups

Micro-Rollups are essentially a state machine that can execute specific logic off-chain and then outsource the verification of the execution results to another layer called "Vulcan," which updates the verification state and puts the computation data on-chain.

• Micro-Rollups' state machine has a well-defined state format and is initialized through genesis conditions;
• The state machine can execute actions (i.e., transaction types), and when these actions are triggered, they call the state transition function on the state machine;
• The state transition function (STF) is responsible for executing computations and updating the state machine's state;

After the STF is executed, all actions are bundled into a block and sent to the Vulcan layer.

The Vulcan layer performs the following operations:

1. Re-executes the actions in the block in a "pessimistic" manner to check the validity of the state transition function (STF);
2. Generates metadata for the verified block;
3. Settles on L1 (main chain) and the data availability layer (DA);

• Sends the updated state of Micro-Rollups to the DA layer;
• Writes the metadata of the verified block and the updated state root hash value to the inbox contract of Micro-Rollups on L1;

The above process collectively constitutes the Stackr Micro-Rollups framework.

Micro-Rollups for Attestation Systems

So, why is Micro-Rollups particularly suitable for building attestation systems? Micro-Rollups have the following advantages:

1. Verifiable off-chain computation: Micro-Rollups functionally resemble backend services, but they add a layer of verifiability to the state and computation of applications, ensuring that the issuers of attestations do not tamper with the system rules;
2. Auditable state: Once the state machine is deployed, the logic of the state transition function (STF) cannot be modified, allowing users to trust that the provider will not arbitrarily change the system rules;
3. Integration with on-chain applications: Micro-Rollups can integrate with on-chain applications, writing the state root hash value of the application to L1, allowing other applications to access the Rollup's state in a provable manner;

Three ways Micro-Rollups are used for attestation

1. Verifiable storage for EAS off-chain attestations

As mentioned earlier, EAS's off-chain attestation is simply a JSON file containing attestation data and signatures, which are not stored on-chain but in private databases or decentralized storage solutions.

Similar to the recommended "verifiable data ledger of the Ceramic network" by EAS, Micro-Rollups is an ideal solution for storing these off-chain attestations. Essentially, Micro-Rollups is a verifiable data ledger because:

• Verifiable computation ensures the correctness of state transitions;
• States are "aggregated" into a hash value (called the Merkle root hash) and published to the Ethereum L1 mainnet at the end of each epoch;
• All data is available to the underlying DA layer;

Such a system would be a generic Micro-Rollups designed to store attestations for any schema registered on EAS, without compromising the verifiability of end users.

2. Micro-Rollups for specific schema attestations

At its core, Micro-Rollups is essentially just a state machine consisting of states and state transition functions. When examining this framework from the perspective of schema and attestation, some similarities can be found.

States are similar to schemas, defining data structures, and attestations are similar to state transitions, which are verified updates that conform to the schema. This comparison highlights the true potential of Micro-Rollups: building Micro-Rollups for specific schemas, allowing attestations to adapt to specific schemas, and giving developers the flexibility to incorporate custom logic into the transition functions, similar to resolver contracts in EAS.

What's even better is that since the computation is entirely off-chain and outside the EVM, users do not need to pay any gas fees when making attestations.

Our recent article on "Micro-Rollups for Point Systems" discussed how applications can use points as an incentive mechanism, which is a direct example of such a system, as points are essentially attestations granted to users by the application.

A wrapper can also be built using Stackr's SDK to easily launch a new Micro-Rollups with custom schema and resolver logic, while maintaining the same API for cross-Micro-Rollups interoperability.

3. Micro-Rollups as an Improvement for EAS

Since Micro-Rollups can abstract away much of the complexity of building decentralized applications, it can be quite quick to implement a near fully functional alternative to EAS as Micro-Rollups. This alternative can provide the same three core functionalities:

• A registry for storing all schemas;
• The ability to create attestations based on schemas;
• The option to revoke existing attestations;

In the next section, we will delve deeper into how to build it.

Let's Build an EAS with Micro-Rollups

Disclaimer: This demo showcases the functionality of the framework and represents an incomplete build, not suitable for production environments. Please consider the content as illustrative rather than a final product.

When developing Micro-Rollups, it is crucial to understand your logic in a state machine manner, which requires careful consideration of the states of Micro-Rollups (i.e., the data it will hold) and the actions that will govern the behavior of the state transition function, which in turn operates on this state.

Having understood the above, let's now start designing the state of Micro-Rollups using Stackr's SDK.

Design

• Schemas and attestations are stored off-chain within the state machine;
• Users send actions to trigger the state transition function within the state machine;
• Users can send actions to register schemas, create attestations for any stored schema, or revoke existing attestations;
• A block is generated at regular timestamps, containing detailed information about the schema and attestation states;
• The block is sent to the Vulcan network for verification;
• If the block complies with the rules of the state machine, it will be approved;
• Block data is settled on L1 and DA;

Establishing Initial State

Similar to EAS, we need to store a list of schemas and attestations. To illustrate this clearly and provide a clear contrast, we will use the same structure as EAS.

1. First, let's define schemas and attestations in our state.

The analysis details are as follows:

• schemas: This field stores a hash map, with the key being the UID of the schema and the value being the SchemaRecord structure, which corresponds to the attestation schema submitted by the user.
• attestations: This field stores another hash map, with the key being the UID of the attestation and the value being the Attestation structure. The Attestation structure corresponds to a single attestation referencing a specific schema.

Adding State Update Handlers

After setting the minimum viable state, we need to define the state transition functions for updating the state.

2. Let's define two functions:

• schema: Responsible for creating schema entries;
• attest: Responsible for creating attestation entries;

Analysis of the registerSchema function:

• When a user submits an instruction to register a new attestation schema, they need to provide two fields: schema: the ABI (Application Binary Interface) of the attestation schema, revocable: whether the schema explicitly allows revocation of attestations;
• The user initiating the registration action will be recorded as the registrar of the schema;
• The state transition function will calculate the unique identifier for the schema entry based on the provided values;
• Finally, the new schema entry is added to the state;

Analysis of the attest function:

• The user submits an instruction to create a new attestation, including the relevant schemaUID and other fields;
• The user initiating the creation action will be recorded as the attestor;
• The state transition function will calculate the unique identifier for the attestation entry based on the provided values;
• The state transition function will compare the incoming attestation data with the ABI of the relevant schema;
• Finally, the new attestation entry is added to the state;

At this point, we have built a minimum viable system.

Smart Contract vs. Micro-Rollups

To retrieve all attestations created for a specific schema or by a specific address, we would need to iterate through all attestation entries. This process would need to be repeated every time we want to perform such a search.

To mitigate this issue, EAS implemented a smart contract called Indexer.sol specifically for indexing values in multiple mapping variables. However, due to the high storage cost in the Ethereum Virtual Machine (EVM) compared to Micro-Rollups, this would incur additional gas fees.

But since we are building a Micro-Rollups, we can use states and computations more freely, prioritizing user experience over cost.

Adding Index Fields to Improve Search Efficiency

3. Add the schemaAttestations field to the state, which will be used to maintain the mapping between schemas and their attestations.

Therefore, when adding a new attestation, we also update the attest function to update the mapping of the schema.

This makes it easy to build a traceable on-chain attestation system similar to the Ethereum Attestation Service, giving backend servers on-chain superpowers. Sounds simple, doesn't it?

Introducing Off-Chain Attestations to On-Chain → Real-World Use Cases and More Possibilities

In the Web3 world, attestations are crucial for enabling most real-world use cases. They bridge the gap between Web2 and real-world identities and Web3, preserving distributed trust.

The beauty of the above system is that it allows for seamless on-chain attestation without incurring significant costs.

As mentioned at the beginning, the state root of Micro-Rollups settles on L1. It is worth noting that developers can choose which parts of the state settle on L1 and which parts serve as metadata on DA, unlocking hybrid security assumptions.

In this case, if we extract attestations and settle their Merkle root on L1, we can directly prove the inclusion of attestations in the Merkle tree.

This feature unlocks the functionality of on-chain identity verification, ownership proofs, and access to various services and rights. For example, JPMorgan recently used a form of proof called verifiable credentials to execute its first DeFi transaction on a public blockchain. When proof data, along with inclusion proofs, is introduced on-chain, the potential for real-world on-chain use cases will explode.

This approach allows for the verification of attestations on-chain without strictly storing the attestations on-chain, resulting in lower costs and better user experience.

Summary

While attestations may seem like a new concept in Web3, they have always been part of our perception of "trust experience." They are crucial for bringing real-world identities and assets onto the chain, directly promoting the legitimacy of blockchain. Essentially, attestations are just another tool for human coordination. With this mental model in place, the only remaining question is: how do we coordinate at the network level?

With its verifiable and fast off-chain computation, auditable state, and integration with on-chain applications, Micro-Rollups provide an ideal framework for building robust attestation systems and coordination mechanisms.

We are only just beginning to bridge the gap between Web2 and Web3.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。