Share Dialog

Micro-Rollups for On-chain Attestations

Micro-Rollups for On-chain Attestations

While EAS provides a solid foundation for reasoning about and utilizing attestations in Web3, it is not without its limitations. Using EAS for on-chain attestations can be cost-prohibitive and requires writing EVM smart contracts for any custom logic. For off-chain attestations, the schema still needs to be on-chain, and developers often store these attestations in private databases, compromising user verifiability.

This situation underscores how micro-rollups built using the Stackr SDK can be used to supercharge the capabilities of EAS or attestations, in general.

Micro-rollups are essentially state machines that executes certain logic off-chain and then outsource the verification of the execution to another layer, which we call “Vulcan” that verifies the state updates and pushes the compute data on-chain.

• The state machine has a defined shape of the state and is initialized with a genesis condition.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan.

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF

2. Generates metadata for the verified block

3. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

So, why are micro-rollups uniquely suited to build attestation systems?

1. Micro-rollups enable verifiable off-chain compute

   Micro-rollups are indistinguishable from backend services but adds a layer of verifiability to the state of the app and the compute.

2. Micro-rollups make the state auditable

   Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

3. Micro-rollups can compose with on-chain apps!

   Micro-rollups settle the state root of the app to the L1. This state root could be a Merkle Root and can be used by other apps to provably access the state of the rollup.

1. Verifiable Storage for EAS off-chain attestations

As highlighted above, an EAS off-chain attestation is just a JSON of attestation data plus a signature. This is not stored on-chain but in private databases or decentralized storage solutions.

In a fashion very similar to the “Verifiable Data Ledger by Ceramic Network” recommended by EAS, a micro-rollup is an ideal solution to store these off-chain attestations. Essentially, a micro-rollup is a verifiable data ledger since:

• verifiable compute ensures correct state transitions.

• the state is “rolled-up” into a hash (read: merkelized) which is posted on Ethereum L1 after each set epoch.

• all data is made available to the underlying DA layer.

Such a system would be a generalized micro-rollup designed to store attestations against any schema already registered on EAS without compromising ease-of-verifiability for the end user.

2. Micro-rollup for schema-specific attestations

At its core, a micro-rollup is simply a state machine comprising of a state and state transition functions. When examining this framework through the lens of schema and attestations, parallels emerge. The state, akin to a schema, defines the data structure, while attestations, akin to state transitions, serve as verified updates that adhere to the schema. This comparison highlights the true potential of micro-rollups: individual micro-rollups can be built tailoring attestations to specific schemas, granting developers the flexibility to incorporate custom logic into transition functions, similar to Resolver contracts in EAS. What makes such a construction even better is that the user making the attestation would incur no gas costs since the computation is done completely off-chain outside the EVM.

Our recent article on Micro Rollups for Points Systems, which talked about points being employed as an incentivization mechanism by applications, is a direct example of such a system as points are essentially attestations bestowed by an application to its users.

Someone could also write a wrapper built on Stackr’s SDK to easily launch a new micro-rollup with custom schema and resolver logic while keeping the same API for cross micro-rollups interoperability.

3. Micro-Rollup as an improvement to EAS

Since micro-rollups abstract away most complexities of building decentralized applications, a near feature-complete alternative to EAS can be implemented as a micro-rollup pretty quickly. This alternative can provide the same three core functions:

• A schema registry for storing all schemas.

• The ability to create an attestation against a schema.

• The option to revoke an existing attestation.

In the following section, we'll delve deeper into how to build this.

Disclaimer: This demonstration showcases the framework's capabilities and represents an incomplete build not intended for production use. Please regard the content as illustrative and not as a finalized product.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK.

• Schemas and attestations are stored off-chain inside a state machine

• User sends actions which trigger a state transition function inside the state machine

• User can send action to register a schema, make attestation referencing any of the stored schemas, or revoke an existing attestation

• After each set epoch a block is generated which contains details of schemas and attestations state

• The block is sent to Vulcan network for verification

• If the block conforms the rules of the state machine it is approved

• The block data is split between L1 and DA for settlement.

Similar to EAS, we need to store a list of schemas and attestations. To illustrate this clearly and provide a stark comparison, we're using the same struct definitions used by EAS.

1.As a starting point, let’s define schemas and attestations in our state.

Breaking this down,

• schemas: stores a mapping of schema UID to SchemaRecord structs where SchemaRecord corresponds to an attestation schema submitted by a user.

• attestations: stores a mapping of attestation UID to Attestation structs where Attestation corresponds to an individual attestation made referencing a schema.

After we setup our minimum viable state, we need to define state transition functions that update the state.

2. Let’s define two functions, registerSchema which is responsible for creating a schema entry, and attest which is responsible for creating an attestation entry.

Breaking down the registerSchema function,

• The user submits an action to register a new attestation schema, providing two fields: schema (the ABI) and revocable (whether the schema explicitly allows revocations).

• The user who initiates the action is recorded as the schema registerer.

• The state transition function calculates a unique identifier for this schema entry based on the provided values.

• Finally, the new schema entry is added to the state.

Breaking down the attest function,

• The user submits an action to create a new attestation, referencing the related schemaUID among other fields.

• The user who initiates the action is recorded as the attester.

• The state transition function calculates a unique identifier for this attestation entry based on the provided values.

• The state transition function verifies the incoming attestation data against the related schema’s ABI (out of scope for this article).

• Finally, the new attestation entry is added to the state.

We’ve reached the point where the minimum viable system works.

To get all the attestations made to a schema or sent by one address, we would need to iterate over all the attestation entries and this has to be repeated each time we want to perform such lookups.

To mitigate this, EAS implements an Indexer.sol smart contract specifically to index the values in several mapping variables. However, this incurs extra gas costs as storage is extremely expensive inside the EVM compared to a micro-rollup.

But since we’re building a micro-rollup, we can be more liberal with the state and compute to prioritise user experience over cost.

3. Adding schemaAttestations to the state.

It’ll be tasked to maintain a mapping between a schema and its attestations.

Accordingly, we update the attest function also to update the mapping for the schema when a new attestation is added.

Voila!

And it’s that simple to build an attestations system akin to Ethereum Attestation Service with on-chain traceability! Surprisingly easy to give on-chain superpowers to a backend server, no?

In the world of Web3, attestations are essential for enabling most real-world use cases. They bridge the gap between Web2 and real-life identity to Web3, preserving distributed trust.

The beauty of the above system is that it allows attestations to seamlessly be used on-chain without severe overhead.

As mentioned at the beginning, micro-rollup’s state root is settled on L1. It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, if we extract the attestations and settle it’s merklized root on L1, we open up the possibility of direct inclusion proofs of attestations in the merkle tree.

This property unlocks on-chain verification of identity, proof of ownership, and access to various services and benefits. For instance, JP Morgan recently used Verifiable Credential, a form of attestation, to execute its first DeFi transaction on a public blockchain. When attestation data is brought on-chain with inclusion proofs, the potential for on-chain real-world use-cases explode.

This approach brings attestations on-chain without the attestations having to be strictly on-chain! (And for significantly cheaper with superior user experience)

Though attestations may seem like a new primitive in Web3, they have always been a part of what we perceive as Trust Experience. They are crucial in bringing real-world identities and assets on-chain, which contributes directly to the legitimacy of blockchains. Essentially, attestations are just another tool for human coordination. With this mental model in place, only one question remains: how do we coordinate at webscale?

Micro-rollups, with their verifiable and fast off-chain compute, auditable state, and ability to compose with on-chain apps, provide an ideal framework for building robust attestation systems and, in turn, coordination mechanisms.

We are only just getting started bridging the gap between Web2 and Web3.

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build an Attestations System for your protocol or building tooling for attestations, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

While EAS provides a solid foundation for reasoning about and utilizing attestations in Web3, it is not without its limitations. Using EAS for on-chain attestations can be cost-prohibitive and requires writing EVM smart contracts for any custom logic. For off-chain attestations, the schema still needs to be on-chain, and developers often store these attestations in private databases, compromising user verifiability.

This situation underscores how micro-rollups built using the Stackr SDK can be used to supercharge the capabilities of EAS or attestations, in general.

Micro-rollups are essentially state machines that executes certain logic off-chain and then outsource the verification of the execution to another layer, which we call “Vulcan” that verifies the state updates and pushes the compute data on-chain.

• The state machine has a defined shape of the state and is initialized with a genesis condition.

• The state machine has actions(read: transaction types) which when invoked trigger a state transition function on the machine.

• The State Transition Function(STF) in effect performs computation and mutates the state of the machine.

After the STF execution, the actions are rolled together in a block & shipped to Vulcan.

Finally, Vulcan —

1. Pessimistically re-executes the actions in the block to check for validity of the STF

2. Generates metadata for the verified block

3. Settles on L1 & DA.

   1. Micro-Rollup’s updated state is sent to the DA.

   2. The metadata of the verified block & the updated state root is settled to the micro-rollup’s inbox contract on L1.

The above pipeline collectively forms Stackr’s Micro-Rollup Framework.

So, why are micro-rollups uniquely suited to build attestation systems?

1. Micro-rollups enable verifiable off-chain compute

   Micro-rollups are indistinguishable from backend services but adds a layer of verifiability to the state of the app and the compute.

2. Micro-rollups make the state auditable

   Once the state machines are deployed, the STF logic cannot be mutated. This enables the users to have an assurance that the provider has not arbitrarily changed the rules of the system.

3. Micro-rollups can compose with on-chain apps!

   Micro-rollups settle the state root of the app to the L1. This state root could be a Merkle Root and can be used by other apps to provably access the state of the rollup.

1. Verifiable Storage for EAS off-chain attestations

As highlighted above, an EAS off-chain attestation is just a JSON of attestation data plus a signature. This is not stored on-chain but in private databases or decentralized storage solutions.

In a fashion very similar to the “Verifiable Data Ledger by Ceramic Network” recommended by EAS, a micro-rollup is an ideal solution to store these off-chain attestations. Essentially, a micro-rollup is a verifiable data ledger since:

• verifiable compute ensures correct state transitions.

• the state is “rolled-up” into a hash (read: merkelized) which is posted on Ethereum L1 after each set epoch.

• all data is made available to the underlying DA layer.

Such a system would be a generalized micro-rollup designed to store attestations against any schema already registered on EAS without compromising ease-of-verifiability for the end user.

2. Micro-rollup for schema-specific attestations

At its core, a micro-rollup is simply a state machine comprising of a state and state transition functions. When examining this framework through the lens of schema and attestations, parallels emerge. The state, akin to a schema, defines the data structure, while attestations, akin to state transitions, serve as verified updates that adhere to the schema. This comparison highlights the true potential of micro-rollups: individual micro-rollups can be built tailoring attestations to specific schemas, granting developers the flexibility to incorporate custom logic into transition functions, similar to Resolver contracts in EAS. What makes such a construction even better is that the user making the attestation would incur no gas costs since the computation is done completely off-chain outside the EVM.

Our recent article on Micro Rollups for Points Systems, which talked about points being employed as an incentivization mechanism by applications, is a direct example of such a system as points are essentially attestations bestowed by an application to its users.

Someone could also write a wrapper built on Stackr’s SDK to easily launch a new micro-rollup with custom schema and resolver logic while keeping the same API for cross micro-rollups interoperability.

3. Micro-Rollup as an improvement to EAS

Since micro-rollups abstract away most complexities of building decentralized applications, a near feature-complete alternative to EAS can be implemented as a micro-rollup pretty quickly. This alternative can provide the same three core functions:

• A schema registry for storing all schemas.

• The ability to create an attestation against a schema.

• The option to revoke an existing attestation.

In the following section, we'll delve deeper into how to build this.

Disclaimer: This demonstration showcases the framework's capabilities and represents an incomplete build not intended for production use. Please regard the content as illustrative and not as a finalized product.

When developing a micro-rollup, it's crucial to conceptualize your logic in terms of a state machine. This involves carefully considering the state of the micro-rollup - that is, the data it will hold - and the actions that will dictate the behavior of the state transition function, which in turn operates on this state.

With the above in mind, we start by designing the state of the micro-rollup using Stackr’s SDK.

• Schemas and attestations are stored off-chain inside a state machine

• User sends actions which trigger a state transition function inside the state machine

• User can send action to register a schema, make attestation referencing any of the stored schemas, or revoke an existing attestation

• After each set epoch a block is generated which contains details of schemas and attestations state

• The block is sent to Vulcan network for verification

• If the block conforms the rules of the state machine it is approved

• The block data is split between L1 and DA for settlement.

Similar to EAS, we need to store a list of schemas and attestations. To illustrate this clearly and provide a stark comparison, we're using the same struct definitions used by EAS.

1.As a starting point, let’s define schemas and attestations in our state.

Breaking this down,

• schemas: stores a mapping of schema UID to SchemaRecord structs where SchemaRecord corresponds to an attestation schema submitted by a user.

• attestations: stores a mapping of attestation UID to Attestation structs where Attestation corresponds to an individual attestation made referencing a schema.

After we setup our minimum viable state, we need to define state transition functions that update the state.

2. Let’s define two functions, registerSchema which is responsible for creating a schema entry, and attest which is responsible for creating an attestation entry.

Breaking down the registerSchema function,

• The user submits an action to register a new attestation schema, providing two fields: schema (the ABI) and revocable (whether the schema explicitly allows revocations).

• The user who initiates the action is recorded as the schema registerer.

• The state transition function calculates a unique identifier for this schema entry based on the provided values.

• Finally, the new schema entry is added to the state.

Breaking down the attest function,

• The user submits an action to create a new attestation, referencing the related schemaUID among other fields.

• The user who initiates the action is recorded as the attester.

• The state transition function calculates a unique identifier for this attestation entry based on the provided values.

• The state transition function verifies the incoming attestation data against the related schema’s ABI (out of scope for this article).

• Finally, the new attestation entry is added to the state.

We’ve reached the point where the minimum viable system works.

To get all the attestations made to a schema or sent by one address, we would need to iterate over all the attestation entries and this has to be repeated each time we want to perform such lookups.

To mitigate this, EAS implements an Indexer.sol smart contract specifically to index the values in several mapping variables. However, this incurs extra gas costs as storage is extremely expensive inside the EVM compared to a micro-rollup.

But since we’re building a micro-rollup, we can be more liberal with the state and compute to prioritise user experience over cost.

3. Adding schemaAttestations to the state.

It’ll be tasked to maintain a mapping between a schema and its attestations.

Accordingly, we update the attest function also to update the mapping for the schema when a new attestation is added.

Voila!

And it’s that simple to build an attestations system akin to Ethereum Attestation Service with on-chain traceability! Surprisingly easy to give on-chain superpowers to a backend server, no?

In the world of Web3, attestations are essential for enabling most real-world use cases. They bridge the gap between Web2 and real-life identity to Web3, preserving distributed trust.

The beauty of the above system is that it allows attestations to seamlessly be used on-chain without severe overhead.

As mentioned at the beginning, micro-rollup’s state root is settled on L1. It is interesting to note that the developer can chose what part of the state settles on L1 vs what part can go on DA as metadata, thereby, unlocking hybrid security assumptions.

In this case, if we extract the attestations and settle it’s merklized root on L1, we open up the possibility of direct inclusion proofs of attestations in the merkle tree.

This property unlocks on-chain verification of identity, proof of ownership, and access to various services and benefits. For instance, JP Morgan recently used Verifiable Credential, a form of attestation, to execute its first DeFi transaction on a public blockchain. When attestation data is brought on-chain with inclusion proofs, the potential for on-chain real-world use-cases explode.

This approach brings attestations on-chain without the attestations having to be strictly on-chain! (And for significantly cheaper with superior user experience)

Though attestations may seem like a new primitive in Web3, they have always been a part of what we perceive as Trust Experience. They are crucial in bringing real-world identities and assets on-chain, which contributes directly to the legitimacy of blockchains. Essentially, attestations are just another tool for human coordination. With this mental model in place, only one question remains: how do we coordinate at webscale?

Micro-rollups, with their verifiable and fast off-chain compute, auditable state, and ability to compose with on-chain apps, provide an ideal framework for building robust attestation systems and, in turn, coordination mechanisms.

We are only just getting started bridging the gap between Web2 and Web3.

We will soon be sharing a more “complete” version of the above mentioned experiment. Until then, if you’re someone who’s looking to build an Attestations System for your protocol or building tooling for attestations, we’d love to talk to you and find ways to collaborate.

Contact us on Discord (preferable), Twitter or shoot an email at gm[at]stackrlabs.xyz

>100 subscribers

>100 subscribers