Decentralized Futures: Establishing efficient zkAuth Support for the Polkadot Ecosystem

Establishing Efficient zkAuth Support for the Polkadot Ecosystem

Status Quo


Polkadot’s Account Abstraction (AA) is an innovative concept introduced to address the challenges associated with managing cryptographic keys on a blockchain. Representing entities from individual identities to institutions’ accounts on blockchains played a crucial role in the Web3 era, where users digitally sign transactions using private keys, and data is recorded on a public ledger.

The loss of private keys, however, poses significant risks, leading to the inaccessibility of digital assets and the fragmentation of digital identity. Creating a new account with a new set of keys becomes a necessity, presenting obstacles for both users and developers concerning security and adoption.

Initially mentioned in Ethereum’s EIP-4337, the concept of account abstraction aims to provide users with flexibility in programming enhanced security and improved user experiences in their accounts. This separation of user experience from private keys enables code to dictate account behavior, increasing the flexibility of initially rigid accounts and reducing the chances of key mismanagement.

Despite the powerful flexibility provided by account abstraction in the Polkadot ecosystem, it currently appears to lack functionalities or components similar to WebAuthn (Web Authentication).

WebAuthn is a modern authentication standard offering robust identity verification. Integrating such identity verification features within the Polkadot ecosystem would enhance security and provide users with more authentication options. The integration of WebAuthn could be a promising direction for the future development of the Polkadot ecosystem, which helps elevate the security and convenience of users’ digital identities, eliminating reliance on passwords, reduces the risks of phishing, brute force attacks, and replay attacks, providing a simpler and faster login process for both Web2 & Web3 Users.

Current Cons in the Polkadot Ecosystem

1. Lack of Grounded ZK Applications in the Polkadot Ecosystem

The absence of concrete and compelling use cases utilizing zero-knowledge technology in the Polkadot ecosystem reveals a deficiency in practical applications grounded in zero-knowledge (zk) technology, which also stifles the ecosystem’s enthusiasm for embracing this cutting-edge technology.

2. Insufficient Onboarding of Mass Users in Polkadot Applications

  • Seamless Integration Challenges: Mass Web2 user onboarding is impeded by the lack of a convenient and user-friendly seamless account system. Overcoming this challenge requires a secure and stable data flow and user-friendly interfaces.
  • Complexity in Identity Management: The existing account management system is not suitable for Web2 users, creating complexities in user identity verification and authentication.

Main value

1. Leveraging the Universality of the Polkadot Ecosystem’s Codebase

Polkadot and all its parachains share a unified codebase, providing a distinctive advantage for the introduction of the zkAuth solution. This enables zkAuth to serve all parachains, leveraging the advantage of deploying once and catering to multiple parachains.

2. Enhancing Privacy and Security in the Polkadot Ecosystem

The zkAuth solution, built upon zero-knowledge proofs, offers users a heightened level of privacy and security. User authentication information is not required to be stored in plaintext on the blockchain, effectively safeguarding user privacy.

3. Reducing User Onboarding Barriers For Polkadot Ecosystem

The introduction of zkAuth significantly enhances the accessibility and lowers the entry barriers for users engaging with Polkadot and its parachains. Users can effortlessly and securely manage their authentication information, enhancing the overall user experience.

4. Increasing the Appeal to Developers and Projects for the Polkadot Ecosystem

By advocating zkAuth technology within the Polkadot ecosystem, it has the potential to attract more developers and projects. This, in turn, encourages the adoption of this innovative technology by a greater number of decentralized applications (DApps), thereby propelling the overall development of the ecosystem. Provide foundational services for enabling on-chain decentralized applications to onboard more Web2 users.


zkAuth Solution

zkAuth provides the ability for Users to send transactions from a Polkadot address using an OAuth credential without publicly linking the two.

This is one of the simplest ways to onboard Users onto the blockchain. zkAuth allows users to log in to Web3 applications using existing Web2 Authentication Providers like Google and Twitch, eliminating the need for users to remember or record private keys.

zkAuth provides great convenience for end users without compromising security. It connects the responses from Web2 Authentication Providers to specific Polkadot accounts using ephemeral keypairs and zero-knowledge cryptography. When using zkAuth, the only data submitted to the blockchain is the zero-knowledge proof, a temporary signature, and some auxiliary data, eliminating the need to submit any user information to the blockchain. Additionally, Web2 Authentication Providers are unaware that users are using the blockchain, ensuring privacy.

In the endeavor to integrate the zkAuth framework into the Polkadot ecosystem, some pivotal aspects are as follows(including both the Frontend and Backend):

Breif WorkFlow

(Step 0) We plan to use Groth16 for our protocol’s zkSNARK instantiation, requiring a singular generation of a structured, common reference string (CRS) linked to the circuit. A ceremony is conducted to generate the CRS, which is used to produce the proving key in the ZK Proving Service and the verifying key in Project Authority.

(Step 1-3) The user begins by logging into an OpenID Provider (OP) to obtain a JWT token containing a defined nonce. In particular, the user generates an ephemeral KeyPair (eph_sk, eph_pk), along with expiry times (max_epoch) and randomness (jwt_randomness). Through these three parameters, the Wallet Extension can thus compute the nonce. After the user completes the OAuth login flow with the nonce, a JWT token can be retrieved.

(Step 4-5) The Account Related Module then sends the JWT token to a Salt Backup Service, which returns the unique user_salt based on the JWT token.

(Step 6) The Wallet Extension sends the ZK Generation Service with the JWT token and some auxiliary inputs. The proving service generates a Zero-Knowledge Proof that takes these as private inputs and does the following: a) Checks the nonce is derived correctly as defined, b) Checks that key claim value matches the corresponding field in the JWT, c) Verifies the RSA signature from OP on the JWT, and d) the address is consistent with the key claim value and user salt.

(Step 7) A transaction is signed using the ephemeral private key to generate an ephemeral signature. Finally, the user submits the transaction along with the ephemeral signature, ZK proof, and other inputs to Chain.

(After Step 7) After submitted on chain, Our ‘Substrate-based’ and ‘Frontier-like’ framework verifies the ZK proof against the provider JWKs from storage (agreed upon in consensus) and also the ephemeral signature.

Frontend Implementation

In the pursuit of creating a user-friendly and frictionless application interface, the frontend implementation plays a pivotal role. The frontend design places a strong emphasis on creating a user interaction-unaware environment, especially for wallet applications. Users will experience a seamless and intuitive interface without the burden of actively managing cryptographic keys or remembering complex authentication procedures.

(Tips: For a more detailed Solution and Code demonstration, please refer to our proposal and the ongoing SDK):

1. extension wallet enables zkAuth

The extension wallet will include:

1.1. Secure Polkadot Account Generation

To bolster the security of Polkadot accounts, the front end will incorporate cryptographic algorithms, ensuring robust key generation. This process involves implementing sophisticated cryptographic techniques to create and manage secure user accounts within the Polkadot ecosystem.

Solution Preview :

During the Generation Phase, the Wallet Extension Account Related SDK should be able to:

  1. Generate and store an ephemeral KeyPair(eph_sk, eph_pk). (Follow the same process as you would generating a KeyPair in a traditional wallet.)
  2. Set the expiration time for the ephemeral KeyPair. The wallet decides whether the maximum epoch is the current epoch or later. The wallet also determines whether this is adjustable by the user.
  3. Generate the JWT randomness(jwt_randomness) for current session.
1.2 Authentication Platform Integration

The front end will possess the capability to seamlessly integrate with authentication platforms, facilitating a smooth user login experience. By interfacing with these platforms, such asGoogle, the application ensures users can authenticate themselves effortlessly, leveraging industry-standard OAuth protocols.

Solution Preview:

During the Authentication Phase, the Wallet Extension Authentication Related SDK should be able to:

  1. Signing in, Fetching and Decoding JWT Token
  2. Generating or restoring user_salt
  3. Constructing User’s Account Address
1.3 zkAuth Transaction Integration

The front end will be empowered with the ability to initiate transactions through zkAuth. Leveraging zero-knowledge proofs, the application can authenticate users and authorize transactions without exposing sensitive information. This privacy-preserving feature enhances the overall security and trustworthiness of user interactions.

Solution Preview:

During the Transaction Related Phase, the Wallet Extension SDK should be able to:

  1. Signing txs via Ephemeral Key
  2. Combining ZK Proof With the previous Sig
  3. Submitting the tx

2. Zero-Knowledge Proof Generation

The implementation includes the capability to handle authentication provider-provided JWT (JSON Web Token) data and perform zero-knowledge proofs on this information and some user’s secret information. This advanced cryptographic functionality ensures the privacy and integrity of user data during authentication processes, offering a secure layer for user accounts and interactions.

Solution Preview:

The Wallet Extension should be embedded with a ZK Proof Generation Service, enabling the local generation of zk proofs, utilizing the groth16 proof system. This is an attestation (proof) over the ephemeral key pair that proves the ephemeral key pair is valid.

Backend Implementation

1. Zero-Knowledge Proof Verification

Based on the Zero-Knowledge algorithms and digital circuits utilized during the frontend’s zkproof generation phase, efficient verification modes that prioritize efficiency and accuracy are needed for implementation in the backend. The backend ensures a robust and streamlined verification process, contributing to the overall efficiency and reliability of the zkAuth system.

2. A frontier-like zkAuth framework

A frontier-like framework will be built to integrate with zkAuth-compatible transactions. This project is designed for universal use within the entire Polkadot ecosystem. We prioritize the robustness and portability of the backend, and in the future, we aim to extend this ecosystem-friendly solution to various relaychains and parachains.

About us

We are the Mimir team; Our mission is to serve as the gateway to the abstraction of Polkadot accounts, providing a convenient and powerful interaction interface for the current account abstractions supported by Substrate. Examples include static multi-sig (based on multi-sig pallet), flexible multi-sig (based on multi-sig + proxy pallets), derivative accounts, and more. Moreover, we aim to further integrate web2 traffic to better support the infrastructure development of Polkadot, through zkAuth.

Currently, we have delivered the best-to-use multi-sig wallet in the Polkadot ecosystem. You can try it at

Contact us:

1 Like