Micro-Rollups’ verifiable off-chain computation, auditable state, and on-chain application integration capabilities may lead to an explosive growth in on-chain real-world use cases.
Written by: stackrlabs
Compiled by: Frank, Foresight News
Attestation is a word with a broad meaning. Almost everyone has some understanding of what it means, and everyone has used this concept unconsciously at some point in their lives.
So let's try to define it, a proof is essentially a statement or assertion made about a piece of information, they serve as evidence or confirmation provided by a trusted party to verify the authenticity of a particular statement. The trustworthiness of a proof depends on the reputation of the entity providing the proof, in the Web3 world, proofs come with a digital signature, ensuring authenticity and immutability.
Let’s look at some examples, both in the real world and in crypto, that you might not realize are actually forms of proof.
Proofs for the Web3 World: Ethereum Proof Service Launches
Ethereum Attestation Service (EAS) is one of the leading projects in the Web3 space to support attestation use cases. It is an open source infrastructure public product for on-chain or off-chain attestation. The way EAS works is very simple. You just need to register a schema on any topic (or use an existing one) and then make attestations based on that schema.
limitation
While EAS provides a solid foundation for proof reasoning and utilization in Web3, it is not without limitations. Using EAS for on-chain proofs can be prohibitively expensive and requires writing EVM smart contracts to implement any custom logic. For off-chain proofs, the architecture still needs to be on-chain, and developers often store these proofs in private databases, compromising user verifiability.
This situation highlights how Micro-Rollups built using the Stackr SDK can be used to enhance the functionality of EAS or attestation overall.
A 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 status and puts the calculation data on-chain.
The state machine of Micro-Rollups has a well-defined state format and is initialized via a genesis condition;
The state machine can perform actions (i.e. transaction types), and when these actions are triggered, the state transition function on the state machine is called;
The state transition function (STF) is responsible for performing calculations and updating the state of the state machine;
After STF execution, all actions will be packaged into a block and sent to the Vulcan layer.
The Vulcan layer does the following:
Pessimistically re-execute the actions in the block to check the validity of the state transition function (STF);
Generate metadata for validated blocks;
Settlements are performed on L1 (main chain) and Data Availability Layer (DA);
Send the updated status of Micro-Rollups to the DA layer;
Write the verified block’s metadata and updated state root hash to the inbox contract of the Micro-Rollups on L1;
The above processes together constitute Stackr's Micro-Rollups framework.
Proof of System Micro-Rollups
So why are Micro-Rollups particularly suitable for building proof systems? Micro-Rollups have the following advantages:
Verifiable off-chain computation: Micro-Rollups are functionally similar to backend services, but add a layer of verifiability to the application’s state and computation, which ensures that the issuer of the proof has not tampered with the system rules;
Auditable state: Once the state machine is deployed, the logic of the state transition function (STF) cannot be modified, which can ensure that the provider will not arbitrarily change the rules of the system;
Can be integrated with on-chain applications: Micro-Rollups can be integrated with on-chain applications. Micro-Rollups will write the state root hash value of the application to L1. Other applications can use this hash value to provably access the state of the Rollup.
Three Ways Micro-Rollups Can Be Used for Proofs
1. Verifiable storage of EAS off-chain proofs
As mentioned earlier, EAS’s off-chain proof is just a JSON file containing proof data and signatures, which will not be stored on the chain but in a private database or decentralized storage solution.
Much like the “Verifiable Data Ledger for Ceramic Networks” recommended by EAS, Micro-Rollups are an ideal solution for storing these off-chain proofs. In essence, Micro-Rollups is a verifiable data ledger because:
Verifiable computation ensures the correctness of state transitions;
The state is “aggregated” into a hash value (called the Merkle root hash) and published to the Ethereum L1 mainnet after each epoch;
All data is available to the underlying DA layer;
Such a system would be a general purpose Micro-Rollups designed to store proofs for any schema registered on EAS without compromising verifiability to end users.
2. Micro-Rollups for Specific Architecture Proofs
At its core, Micro-Rollups is essentially just a state machine consisting of states and state transition functions. When looking at this framework from the perspective of architecture and proof, we can find some similarities.
State is analogous to architecture, it defines the data structure, while proofs are analogous to state transitions, they are verified updates that conform to the architecture. This contrast highlights the true potential of Micro-Rollups: Micro-Rollups can be built for specific architectures, enabling proofs to adapt to specific architectures and giving developers the flexibility to incorporate custom logic into transition functions, similar to Resolver contracts in EAS.
Even better, since the computation is done entirely off-chain, outside of the EVM, users do not need to pay any gas fees when making proofs.
Our recent post on Points System Micro-Rollups discusses how applications can use points as an incentive mechanism, which is a direct example of such a system, as points are essentially proof that the application has granted them to users.
It is also possible to build a wrapper using Stackr's SDK to easily spin up a new Micro-Rollups with custom schema and parser logic while keeping the same API for interoperability across Micro-Rollups.
3. Micro-Rollups as an Improvement Solution for EAS
Since Micro-Rollups abstract away much of the complexity of building decentralized applications, a nearly feature-complete EAS alternative that provides the same three core features can be implemented fairly quickly as a Micro-Rollup:
A schema registry to store all schemas;
The ability to create proofs based on the architecture;
option to revoke existing certification;
In the next section we'll take a closer look at how to build it.
Let’s build an EAS using Micro-Rollups
Disclaimer: This demo shows the functionality of the framework, represents an incomplete build and is 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 terms of a state machine, which requires careful consideration of the state of the Micro-Rollups (i.e. the data it will hold) and the actions that will govern the behavior of the state transition functions, which in turn operate on this state.
With the above understanding, we will now start to design the state of Micro-Rollups using Stackr's SDK.
design
The schema and proofs are stored off-chain inside the state machine;
The user sends an action, triggering the state transition function inside the state machine;
Users can send actions to register a schema, create a proof against any stored schema, or revoke an existing proof;
A block is generated at every given timestamp, containing details of the architecture and proof status;
The block is sent to the Vulcan network for verification;
If the block complies with the rules of the state machine, the block is approved;
Block data will be split into L1 and DA for settlement;
Determine the initial state
Similar to EAS, we need to store lists of schemas and proofs. To make this clear and provide an obvious comparison, we will use the same structure definition as EAS.
1. First, let's define the architecture and proofs in our state.
The analysis details are as follows:
schemas: This field stores a hash map, the key is the UID of the schema, the value is the SchemaRecord structure, and the SchemaRecord structure corresponds to the proof schema submitted by the user.
attestations: This field stores another hash map, with the key being the attestation's UID and the value being an Attestation structure. An Attestation structure corresponds to a single attestation that references a specific schema.
Adding a status update handler
After setting up the minimum viable state, we need to define the state transition function used to update the state.
2. Let's define two functions:
schema: responsible for creating schema entries;
attest: responsible for creating attestation entries;
Analyze the registerSchema function:
When a user submits an instruction to register a new attestation schema, two fields need to be provided: schema: the ABI (Application Binary Interface) of the attestation schema, revocable: whether the schema explicitly allows the attestation to be revoked;
The user who initiates the registration action will be recorded as the registrant of the schema;
The state transition function calculates a unique identifier for the schema entry based on the provided value;
Finally, add the new schema entry to the state;
Analyze the attest function:
The user submits an instruction to create a new certificate, which contains fields such as the relevant schemaUID;
The user who initiated the creation action will be recorded as the prover;
The state transition function calculates a unique identifier for the proof entry based on the provided value;
The state transition function compares the passed proof data with the ABI of the relevant architecture;
Finally, the new proof entry is added to the state;
At this point, we have built a minimum viable system.
Smart Contracts vs. Micro-Rollups
To get all the attestations created for a schema, or issued by a certain address, we need to iterate over all attestation entries, and we need to repeat this process every time we want to do such a lookup.
To alleviate this problem, EAS implements a smart contract called Indexer.sol, which is specifically used to index values in multiple mapping variables. However, since the storage cost in the Ethereum Virtual Machine (EVM) is very expensive compared to Micro-Rollups, this will incur additional Gas fees.
But since we are building a Micro-Rollups, we can use state and computation more freely, prioritizing user experience over cost.
Add index fields to improve search efficiency
3. Add a schemaAttestations field in the state, which will be used to maintain the mapping between the schema and its attestations.
Therefore, when new attestations are added, we also update the attest function to update the schema's mapping.
In this way, you can easily build an on-chain proof system with traceability similar to Ethereum's proof service, giving the back-end server on-chain superpowers. Sounds simple, right?
Bringing off-chain proofs to the chain → real-world use cases and more possibilities
In the Web3 world, proofs are critical to 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 proofs to be used seamlessly on-chain without incurring a lot of overhead.
As mentioned at the beginning, the state root of Micro-Rollups is settled on L1. It is worth noting that developers can choose which parts of the state are settled on L1 and which parts are placed on DA as metadata, thereby unlocking hybrid security assumptions.
In this case, if we extract the proof and settle its merklized root on L1, we can then do a direct subsumption proof of the proof in the merkle tree.
