Mina Wallet via Google OAuth - Lit Protocol Integration

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @invoicez
Please see below for the details of the proposal and discussion.

25th November, 2024
Current status: Under Consideration.
Opened for community discussion on: 25th November, 2024.

2

User wallets using Google OAuth. Built using Lit Protocol

Project Background

The project began as part of a 6-month initiative during the Navigators Season 1 program, focused on developing a minimum viable product (MVP) for an invoice application. This application utilizes Zero-Knowledge (ZK) proofs and operates on the Mina protocol. The core concept of the project is centered around using recursive proofs to build a verifiable off-chain invoice repository. This repository is intended to be used on-chain for various applications, such as facilitating credit assessments or enabling on-chain invoice factoring.

The project’s goal is to create a system where invoice data can be kept secure off-chain and still be confirmed via on-chain mechanisms, ensuring both data integrity and privacy. Through the use of the Mina protocol, the project satisfies critical invoicing system needs by balancing privacy with transparency.

As we aim to introduce the Invoices platform on Mina to its initial users, we recognize a significant learning curve for Web2 users due to the complexities involved in onboarding. To address this, we propose a seamless, extensionless onboarding solution that eliminates the need for wallets, thus simplifying the process for users entering the Mina ecosystem.

Proposal Overview

  • Problem:
    One major challenge in onboarding Web2 users to decentralized apps is the need to install browser extensions and create wallet keys. This process creates friction, discouraging those unfamiliar with blockchain technology. Traditional users, used to seamless Web2 experiences, may find these technical steps daunting, leading to higher dropout rates and potential loss of users.

  • Solution:
    Aiming to streamline the transition of Web2 users to Web3, this onboarding tool reduces technical complexities. It provides a simplified authentication process similar to ‘Sign in with Google’, allowing users easy access to decentralized apps. By making wallet creation and key management more intuitive, the tool seeks to improve user retention and expand the reach of decentralized applications to a broader audience.

    This tool eliminates the need for browser extensions, providing a more accessible entry point for users to engage with decentralized applications. By removing the requirement for additional software, it significantly reduces adoption barriers for traditional users.

    This tool also aims to support the original mina-provider, enabling developers to build apps compatible with this solution alongside existing wallets like Auro Wallet.

  • Impact:
    This proposal enhances the Mina ecosystem by lowering barriers for new users, thus encouraging broader adoption. By simplifying the onboarding process, it attracts more users who are traditionally hesitant about blockchain technology due to technical complexities. Additionally, it offers developers improved tools for integrating their applications, consequently fostering innovation and enabling novel applications within the Mina ecosystem.

  • Audience:
    The target audience for this project primarily includes developers who are looking to create user-friendly decentralized apps. By providing tools that simplify onboarding, it empowers developers to design applications that are more accessible to users. Additionally, the project targets Web2 users interested in exploring decentralized applications but are deterred by complex onboarding processes, as well as businesses aiming to integrate Web3 elements without alienating their existing user base.

Architecture & Design

The project integrates Lit Protocol to enhance key management capabilities. Although Lit Protocol is predominantly engineered for Ethereum keys, it also offers adaptability for managing keys not natively supported by the protocol.

Detailed Design/Architecture

Generate a Programmable Key Pair (PKP).

Programmable Key Pairs (PKPs) are ECDSA public/private key pairs created by the Lit network using Distributed Key Generation (DKG). Each Lit node holds a share of the private key, and more than two-thirds of these shares must be collected to execute a given action (i.e. signing a transaction).

Programmable Key Pairs (PKPs) will serve as the authentication factor, enabling encryption and decryption operations as well as controlling access within Lit Protocol. By leveraging the distributed key generation process, PKPs ensure that sensitive operations can only be performed with the approval of the network’s consensus, adding a robust layer of security to key management. This mechanism enhances trust by distributing control across the network and ensures that private keys are managed efficiently and securely. Users will thus benefit from both increased data protection and streamlined access management, facilitating a more secure interaction with decentralized applications.

Create a Custom Wrapped Key

Wrapped Keys are a secure and flexible key management solution provided by Lit Protocol. They offer a unique approach to handling private keys, combining the security of encryption with the programmability of Lit Actions to offer private key signing to a broader range of blockchain networks.

Lit actions are utilized to generate, encrypt, and store a Mina Key, ensuring secure key management throughout its life cycle. By employing Lit Protocol’s advanced cryptographic capabilities, this process enhances the security of the key storage and accessibility. The encryption protects the key from unauthorized access, while distributed storage across the network improves reliability and safety. These features collectively streamline key operations, making interaction with the Mina blockchain both efficient and robust.

How is this key used for signing operations

Lit Actions are immutable JavaScript programs that run on a decentralized Lit network. They enable powerful, blockchain-agnostic applications with built-in cryptographic capabilities like signing and encryption.

  • The process of using keys for signing operations involves several secure and systematic steps aimed at ensuring both security and efficiency. Initially, PKP (Programmable Key Pair) is used to acquire session signatures that grant access to the Lit Protocol.
  • With these session signatures, you can retrieve all related custom wrapped keys, which are fundamental to the subsequent operations.
  • The next step involves fetching the encrypted key data securely stored on Lit Servers. (These encrypted keys can be stored by the developer as well)
  • Once the encrypted key data is obtained, it is accompanied by the session signatures and the intended message, and then supplied to a Lit Action.
  • The Lit Action then securely decrypts the key within a Trusted Execution Environment and executes the signing of the message, providing a robust mechanism for secure digital interactions.

Security of Custom Lit Actions

A document from Lit Protocol describes the security of Lit Actions in detail: Deploying Your Lit Action | Lit Protocol

Architecture Diagram

Vision

Use Mina with social authentication methods

Developers can integrate social logins like Google, Facebook, or Twitter to create keys on Mina, simplifying user onboarding. This approach eases entry for blockchain newcomers, extending Mina’s reach and usability by leveraging its cryptographic strengths.

Use Mina with Ethereum Wallets

This extension broadens key generation management to include Ethereum wallets. Developers can allow users to leverage their existing Ethereum wallets, such as MetaMask or WalletConnect, for seamless key integration. This approach not only enhances user convenience but also eliminates the need for generating new Programmable Key Pairs (PKPs), thereby streamlining the onboarding process for those already familiar with Ethereum’s ecosystem.

Multi-Factor Authentication for Key Use

By utilizing conditional decryption, developers can implement a structure that mandates multiple signatures for accessing keys. This strategy significantly strengthens security by incorporating multi-factor authentication, thereby bolstering signing processes.

Consider a situation where you authenticate to an application using a Google login but must complete a Passkey/TOTP verification before proceeding with a transaction signing.

Social and Ethereum Multi-signature Using Unified Keys

By storing transactions and decrypting them using Lit actions, we can create a multi-signature framework that requires authorization from several parties. Each of these parties can use either a Mina Wallet, Ethereum wallet, or a social authentication wallet, providing flexibility and enhanced security.

Existing Work:

Integration Steps

  • Google Authentication: The SDK comes with google authentication out of the box. It is not required to create a new google application, but developers can integrate their own google applications. They can pass google OAuth redirect URI while configuring the Lit-mina-signer SDK.

  • Lit Protocol API Key: The SDK uses default relayer to interact with Lit Protocol Network. To use the relayer, developers need to fill a form provided by Lit Protocol to get an API Key. Form Link: Relay Server API Key Request Form

Removing Dependency on Lit Protocol API Key

Lit Relayer is a open source, and this can be deployed by developers to remove the need for Lit Protocol API Key.

Link: GitHub - LIT-Protocol/relay-server: Relay server to facilitate and subsidize some interactions with smart contracts.

Code Snippets

This shows a high level snippet of how mina signer can be integrated

import LitMinaSigner from "lit-mina-signer";
import MinaSigner from "mina-signer";

const signer = new MinaSigner({ network: "mainnet" });

function App() {
  const {
    ready,
    authenticate,
    googleSignIn,
    keys,
    signMessageWithKey,
  } = useContext(LitMinaSigner);

  async function signAndVerifyMessage() {
    const message = prompt("Enter a message");

    const signedMessage = await signMessageWithKey(keys[0], message as string);

    const verified = signer.verifyMessage({
      data: message as string,
      signature: signedMessage.signature,
      publicKey: key,
    });

    window.alert(verified ? "Message Verified" : "Message Not Verified");
  }
  
  if (!ready) {
    return <p>Loading</p>
  }
  
  if (keys.length === 0) {
    return (
      <Button onClick={googleSignIn}>Authenticate With Google</Button>{" "}
    );
  }
  
  return <div>
    <Button onClick={signAndVerifyMessage}>Test Sign</Button>
  </div>
}

Lit Protocol Mainnet

Lit Protocol is being used by many applications in Datil mainnet. The list of applications include Lens Protocol.

More information present at:

Is using Lit Protocol Secure?

This SDK uses custom wrapped keys. These are built using Custom Actions. Lit Protocol nodes performs execution in a TEE. The working of lit protocol is described in great detail at: How Does Lit Protocol Work | Lit Protocol

How much does it cost to use Lit Protocol?

Lit Protocol is free to use at the moment. It is experimenting with payment models and offers multiple approaches to abstract payment methods to use Lit Protocol.

Like other decentralized networks, Lit has a certain amount of computation available for users that’s metered to allow for a responsive network with nodes that are able to stay in-sync with one another.
When using the Lit networks - whether it’s the decentralized testnet (Datil-test) or the production-ready mainnet beta (Datil) - you need to pay for and reserve your usage. This is accomplished using Capacity Credits.
To streamline the payment process and facilitate integration into your apps, Lit offers two tools: the Lit Relayer and the Payment Delegation Database. These tools allow you to seamlessly incorporate Lit functionality without burdening your users with the need to acquire Lit test tokens or mint Capacity Credits on their own.

Described in detail at Paying for Usage of Lit | Lit Protocol
Lit Protocol Token: How Does Lit Protocol Work | Lit Protocol

Production Timeline

For the scope of this proposal, we are targeting to support operations like signing transactions, signing payments, and other simple operations, with a focus on enhancing functionality and ensuring seamless integration with existing systems.

  • Alpha Release (End of this year):

    • Focus on developing core functionalities such as transaction and payment signing.
    • Initial testing to ensure basic operations are stable and reliable.

  • Beta Release (First Quarter 2025):

    • Release comprehensive documentation.
    • Onboard developers for extensive testing and feedback collection.
    • Expand features based on initial user feedback to enhance usability.

  • Stable Release (Second Quarter 2025):

    • Perform extended testing to iron out any remaining issues.
    • Finalize and polish the utility for public release.
    • Focus on stability, security, and optimizing performance for real-world use.

Links

Budget & milestones

This section should detail the deliverables at the end of the funding period, mid-point milestones, timeline and the budget requested. It should explain how the budget will be spent.

Deliverables: First alpha release

In this project we will publish multiple npm packages. These packages will include the core TypeScript modules that are used for signer, and helper react libraries.

With the first alpha release, we plan to add partial support for mina-provider. This includes operations like:

Account Management

  • Enable creation of multiple accounts through Google authentication
  • Provide React hooks for accessing account details such as transaction history and balance
  • Allow exporting of private keys
  • Offer various options for private key storage, including Lit Protocol hosting, self-hosting, and hosting by Invociez

Signing and Transactions

  • Signing data (message, fields, etc.)
  • Sending zk app transactions
  • Sending payment transactions
  • Viewing history of transactions

Optional View Components

  • Pluggable react components for managing accounts
  • Modals for signing data and transactions

Mid-Point milestones:

  • Enable creation of multiple accounts through Google authentication
  • Signing data (message, fields, etc.)
  • Sending zk app transactions
  • Sending payment transactions

Budget & milestones

  • Project Timeline : 2M

  • Budget Requested : 24000 MINA

  • Budget Breakdown: This budget will be used for development, testing and documentation of the library.

  • Wallet Address: B62qrbUDrAnnqP8SZXq29ood7VUASE5CVUiAuj4cHbgAr6FFAKRuTiv

Team Info

  • Proposer Github: kriss1897 (kriss1897) · GitHub
  • Proposer Experience: I have been part of the Mina community for over 2 years and have been an active blockchain developer for the past 5 years. In this period, I’ve participated in various freelance and hackathon projects, securing top-3 prizes in three hackathons on the Lukso Network. Before transitioning to blockchain development, I spent roughly 3 years as a full stack developer.
  • Team Members:
    • kriss1897
  • Achievements:
    • Developed a browser cache adapter that significantly reduced web browser compilation time, becoming a widely adopted resource among MINA developers. - Contributed to Mina’s developer community through discussions and support in community forums and Discord join the conversation.
    • Built a proof of concept for an Invoices application during the navigators program, consistently achieving all milestones over the six-month duration.

Risks & Mitigations

  • What risks or dependencies do you foresee with building this project?

    • The project relies on Lit Protocol, which natively lacks support for Mina keys. Consequently, creating custom wrapped keys becomes necessary, leading to single-node decryption as opposed to distributed signing used with Ethereum keys.
    • The focus on React for the view layer may limit accessibility for developers using alternative libraries or frameworks such as Vue.

  • What are your mitigations, if any?

    • Research ways to enhance support for Mina keys by enabling multi-node decryption, thereby improving security.
    • Investigate standard account solutions that accommodate ECDSA signatures to allow the use of Ethereum signatures.
    • Once the concept is adopted and validated, develop additional adapters to support various UI frameworks.
    • Another alternative to the “decryption to a sigle node” can be to use just encryption without wrapped keys. So the key is decrypted on user’s device directly and not in the Lit network node. But the limitation of this approach is that, multi sig implementations cannot be done using this.
3 Likes