Alin Tomescu

Keyless blockchain accounts on Aptos

 
  • Jun 13, 2024

tl;dr: What is a keyless blockchain account? Put simply, “Your blockchain account = Your Google account”. In other words, this keyless approach allows you to derive a blockchain account from any of your existing OpenID Connect (OIDC) account (e.g., Google, Apple), rather than from a traditional secret key or mnemonic. There are no long-term secret keys you need to manage. There is also no multi-party computation (MPC) system managing your account for you. As a result, the risk of account loss is (more or less), the risk of losing your Google account. Keyless is built using a Groth16 zero-knowledge proof to maintain privacy in both directions: prevent the blockchain from learning anything about your Google account & prevent Google from learning anything about your blockchain account and transaction activity.

One day, I hope to edit this into a full blog post but, until then, here’s a bunch of resources.

Drawings

Keyless on-chain verification

Depicts what the blockchain validators need to do to verify a keyless TXN submitted by a user, Alice.

End-to-end keyless ZK flow

Depicts the full keyless flow: the user generating an ESK and EPK, the user signing into the dapp with the EPK as the OIDC nonce, the dapp getting a JWT, exchanging it for a pepper, getting a ZKP from the prover service, the user signing a TXN with their ESK, the dapp sending the TXN containing the ZKP and ephemeral signature, and finally the blockchain verifying everything.

Keyless ZK relation

The ZK relation needed for keyless:

Oblivious pepper service ZK relation

The ZK relation needed to implement an oblivious pepper service:

End-to-end-keyless ZKless flow (disabled)

In case of emergency (e.g., a serious soundness issue in the ZK circuit), keyless supports a ZKless mode that is not privacy preserving. This, of course, is currently disabled on Aptos mainnet.

We depicts this (simpler) ZKless flow: the user generating an ESK and EPK, the user signing into the dapp with the EPK as the OIDC nonce, the dapp getting a JWT, the user signing a TXN with their ESK, the dapp sending the TXN containing the ephemeral signature, and finally the blockchain verifying everything.

Write-ups

  1. I wrote a high-level overview of how keyless accounts work on the Aptos blockchain
  2. I wrote an in-depth explanation of how keyless accounts work (and their many caveats) in the 61st Aptos Improvement Proposal.

Slides

Code

  • Example: Sending a keyless TXN to the Aptos mainnet via the SDK here
  • Example: Simple Keyless dapp on Aptos here with guide here
  • Example: End-to-end dapp with Keyless here with guide here
  • Keyless blockchain validator logic here
  • Keyless governance logic here
  • Keyless SDK here

Aptos Improvement Proposals (AIPs)

AIPs for auxiliary keyless services:

AIPs for recent extensions to keyless:

Tweets

A tweetstorm summarizing Aptos Keyless can be found below:

Presentations

In April 2024, I gave a 20-minute presentation at zkSummit11:

Search