I am excited to share with the new project we are working on called OP Passport. This initiative, funded by the OP Season 5 Builder Grant, aims to enhance the privacy, security, and active participation of governance on the Optimism.
Get Involved
We invite the Optimism community to review this design document and provide feedback. Your insights and suggestions will be invaluable in refining and improving the OP Passport project.
Your feedback is crucial to ensure we build a robust and effective platform that meets the needs of all governance participants. We look forward to your thoughts and suggestions!
Introduction
-
Project Overview: The OP Passport project aims to develop an open-source platform for governance participants on Optimism, utilizing Zero-Knowledge Proof (ZKP) technology for privacy-preserving attestations and on-chain identity passports. The platform enhances privacy, security, and active participation of governance by enabling participants to issue and manage their on-chain identity passports.
-
Purpose of the Document: This design document outlines the framework, badge criteria, visual designs, attestation mechanisms, and integration of ZK technology, providing clear guidance for the development and implementation of the OP Passport system.
System Framework
-
Architecture Overview:
- The system architecture includes the front-end web interface, back-end services, smart contracts, and a database for tracking user achievements and badge issuance. The architecture is designed to ensure privacy and security through the integration of ZK technology.
-
Core Components:
- OP Passport Frontend: Web interface for users to interact with the platform.
- Database: Storage for user data, badge issuance records, and attestations.
- Back-End Service
- Curia Indexer: Indexed data from on-chain and off-chain. This indexed data will be stored in the database for the criteria for each badge issuance record.
- Issuer: The backend service that is responsible for issuing badges to users. It also acts as a relayer for anonymous attestation.
- Smart Contracts: Blockchain-based contracts for badge minting, identity attributes, and ZK proofs.
- Resolver: for validate on-chain criteria on endorsement attestation and verify proof & signature on anonymous attestation.
- Smart Account: smart contract account as passport and act as identity layer for each user.
-
Integration Points:
- OP Mainnet and OP Sepolia Testnet: Deployment environments for the platform. The lists of the contracts that OP Passport need to interact will be as follows:
- OP Contract: for votes and delegates data
- Gov Contract: for governance participation data
- EAS Contract: to issue new attestation and retrieve existing attestation data (ex. Badgeholder information, etc.)
- Alligator Contract: for partial delegation information.
- EAS Schema Registry: to register new schema for OP Passport.
- Account Factory: to create a new Smart Account for holding OP Passport and act as the identity layer for each user.
- Governance Database: Integration for reliable data attestation and verification of governance activities.
- OP Mainnet and OP Sepolia Testnet: Deployment environments for the platform. The lists of the contracts that OP Passport need to interact will be as follows:
Features
- Digital Passports:
- Functionality for creating and managing digital identity passports.
- Integration with on-chain identity attributes.
- Badge Issuance:
- Mechanism for issuing badges based on predefined criteria.
- Smart contract integration for badge minting and management.
- Public and Anonymous Attestations for Endorsement:
- Options for users to create public or anonymous attestations.
- Workflow for generating and verifying attestations.
- User Dashboard:
- Dashboard for users to view their badges, attestations, and passport status.
- Analytics and insights on user participation and engagement.
Governance Participant Roles
- Roles:
- Delegates: Individuals who receive delegated voting power to participate in governance.
- Delegators: Individuals who delegate their voting power to delegates.
- Badgeholders: Members of the Optimism Citizens’ House who vote on the allocation of Retro Funding.
Badge
- Criteria Definitions:
- Delegate
- Voting Power: based on the amount of OP controlled:
- Top Voting Power Ranking:
- Delegate Address Count: Reflect the breadth of trust
- Voter Turnout/Participation Rate: Ensure active participation
- Status: Encourage ongoing activity:
- Active, Inactive, Ghost
- Seasonal Participation: Recognize long-term contributors:
- Badge for each season participated
- Votes on Proposals: Reward frequent voters:
- Delegate Expansion: Attracting New Delegator
- Partial Delegation
- Receive Partial delegation
- Delegator Metrics:
- Duration of Delegation: Reflect commitment:
- Amount Delegated:Indicates the amount of voting power delegated.
- Noted that some of the Delegate metric still applicable to Delegator metric since delegator is the one who delegate their voting power
- Badgeholder:
- Votes on Proposals: Reward frequent voters:
- Round Participation: Recognize long-term contributors:
- Badge for each Round participated
- Delegate
- Badge Types:
- Gaming-style, with progressive levels (3-5) based on achievement criteria.
- Issuance Conditions:
- Badges are issued by the Curia team each season. Data is collected at the season’s end to determine achievement levels for each metric.
Visual Designs
Attestation Mechanisms
We support peer to peer message attestation with customized identity roles with realtime roles validity check through EAS resolver, our design is compatible with existing EAS mechanism.
- Attestation Types:
- Message attestation with customized identity roles
- Badgeholders
- Delegates
- Delegators
- Message attestation with customized identity roles
- Workflow:
- Users submit attestation through our passport-frontend or directly through smart contract on Optimism at our EAS schema contract.
- The EAS schema contract call role resolver contract.
- The role resolver contract call customized role validity checker for each customized role
- Badgeholders are identified by on-chain address registry which is also viewable and challengeable by third party
- Delegates and Delegators are identified by OP token contract inside getVotes and delegates view functions
- If the resolver returns true, then emit the attestation. The transaction is completed per user perspective.
- Curia Indexer picks all attestations for the schema up.
- The attestation can be viewed through our passport-frontend in both attester and attested address.
- Schema Definitions:
- The attester and attested are already included in EAS attestation info by default so we omit this in the data part.
- {role: string, message: string}
Anonymous Attestation Mechanism
Anonymous Attestation Mechanism
In addition to normal attestation we also aim to support anonymous attestation in the same manner, in this case, peer to peer message attestation with customized identity roles. Anonymous in this case refers to instead of revealing attester we hide them instead while valid identity roles are still shown.
- ZKP Overview:
- To achieve this, we utilize a cryptographic primitive called zero knowledge proof, this allows us to hide some information while guaranteeing an enforced correct statement for such information. In this case, identity roles.
- Chosen ZKP Protocols:
- We choose UltraPlonk (zkSNARK) to be our ZK scheme and will be implemented using Noir (https://noir-lang.org/) due to ease of development, community support, and tooling.
- Implementation Details And Workflow:
-
We came up with 2 possible variants of the anonymous attestation mechanism, each having different pros and cons. In the sense of user perspective, other workflows other than the ZK part would still be the same.
-
ZK Proof Generation
- Curia Signature
- Identity role proof is generated by verifying Curia signature. The signature and address verification is obtained off-chain from passport-frontend. Address verification process is done through either ECDSA signature verification (native signature), or EDDSA signature verification (derived signature from registered keypair, intended for AA account)
- User request to do anonymous attestation to target address on some message
- User send signature verifying their ownership of address to Curia through passport-frontend (signature can be ECDSA or registered EDDSA)
- Curia gives back a signature that guarantees ownership of the address with the identity role. This signature is signed on address and identity role.
- Calculate revoker using hash of address and signature
- User generate ZK Proof that proof that
- User know a valid Curia signature that sign on the specific address
- Signature signed by that specific address on “CURIA_ANONYMOUS_ATTESTATION_V1” message is valid
- Attestation message is attached in public input
- Random nonce is attached in public input
- Revoker hash (hash of revoker) is correctly calculated and is attached in public input
- Pros:
- Support real time role update
- Infinite identity group (We can support arbitrary identity groups ex. Top 10 Delegate, etc.)
- Very fast and not heavy computation dependent.
- Curia also has zero knowledge to link which attestation has been done if the requested signature pool is large enough.
- Cons
- Rely on Curia infrastructure.
- Building blocks are not designed to be composable.
- Identity role proof is generated by verifying Curia signature. The signature and address verification is obtained off-chain from passport-frontend. Address verification process is done through either ECDSA signature verification (native signature), or EDDSA signature verification (derived signature from registered keypair, intended for AA account)
- Semaphore Group
- Identity role proof is generated by verifying Semaphore group’s merkle tree inclusion of the address and the address ownership verification similar to Curia Signature method (ECDSA and EDDSA). The Semaphore group of each identity role is updated on-chain by Curia every 2-months interval (corresponding to Passport’s season).
- User request to do anonymous attestation to target address on some message
- User fetch all semaphore merkle tree leafs
- User generates a signature verifying their ownership of the account.
- Calculate revoker using hash of address and signature
- User generate ZK Proof that proof that
- User knows the merkle path from their address leaf to the root.
- Signature signed by that specific address on “CURIA_ANONYMOUS_ATTESTATION_V1” message is valid
- Attestation message is attached in public input
- Random nonce is attached in public input
- Revoker hash (hash of revoker) is correctly calculated and is attached in public input
- Pros:
- Very decentralized.
- Proof and attestation transactions can be generated without interacting with Curia.
- All addresses in each group are verifiable.
- Cons:
- Computationally and communicationally expensive.
- Not real-time at all.
- Group membership update is very costly due to the large membership size nature.
- Identity role proof is generated by verifying Semaphore group’s merkle tree inclusion of the address and the address ownership verification similar to Curia Signature method (ECDSA and EDDSA). The Semaphore group of each identity role is updated on-chain by Curia every 2-months interval (corresponding to Passport’s season).
- Curia Signature
-
Then the proof is submitted to the relayer which the relayer then will call the “Curia Anonymous Attestation” contract. This contract will then verify the zk proof and call attestation function at EAS on behalf of the user.
-
Result of attestation would be “Curia Anonymous Attestation” contract attest to target address.
-
Anonymous attestation can be revoked by calling “Curia Anonymous Attestation” contract and providing uid of the attestation and preimage of “Revoker hash” submitted in the attestation. If the contract can correctly verify Revoker hash preimage, then the contract will call revoke at EAS on behalf of the user.
-
9. Smart Account Wallet:
The smart account wallet serves as a comprehensive digital repository, designed to securely store and manage each participant’s on-chain identity passport along with their related attestations, providing an accessible record of their governance roles, contributions, and achievements within the Optimism collective.
- Smart Account Wallet Overview:
- A smart contract wallet is a type of Ethereum account that is managed by a smart contract instead of an externally owned account (EOA) private key. They can have benefits like multi-signature capability, and can be customized to serve more specific use cases.
- Chosen Smart Account Wallet
- We chose Safe (CORE) to be our base implementation for our smart wallet account. Safe (CORE) is modular, battle-tested, and has been used by many projects. It also has great tooling and community support. We explored the Account Abstraction approach, but we think it may not be needed for the first version.
- Implementation Details And Workflow:
- Users create OP Passport from OP Passport frontend.
- System will create new smart account, add user address to signer and register this smart account address to the system
- System will create attestation and badge to this smart account address (and additional fields like ens, user EOA address for reference.)
)