# Schnorrkel.js: Efficient Multi-sigs via Schnorr Signatures

## Abstract
Multi-signatures are one of the most powerful constructs in Web3. Other than enabling DAOs and corporate treasuries, they also serve to improve personal security in the form of multi-factor authentication, for example signing a transaction on your laptop and mobile phone, which with modern secure enclaves can rival hardware wallets in terms of security, if not surpass them.

Historically there have been multiple ways to implement multi-signatures, from the naive on-chain multisig code, like ~~Gnosis~~ Safe, to multi-party computation on ECDSA.

However, there is a way to do it that is cheap to verify on-chain, easy to implement, and extremely flexible: Schnorr signatures. **We propose a JS library that can construct Schnorr aggregate signatures that can be verified on-chain for the cost of a regular `ecrecover`.**

Currently, the library is in [prototype stage](https://github.com/borislav-itskov/schnorrkel.js).

## Why Schnorr signatures + account abstraction is a powerful combo

- Traditional EOA accounts cannot verify Schnorr signatures; however, by using Schnorr + AA instead of MPC over ECDSA, we open up the possibility for far more mature libraries and signature schemes to be used, which is great for security and flexibility
- Unlike MPC on ECDSA, key rotation is much easier and doesn't require complex and potentially centralized key redistribution schemes
- Unlike MPC on ECDSA, Schnorr signing requires significantly fewer rounds of interactivity, making it as simple as regular fully on-chain multi-sigs
- Unlike regular on-chain multi-sigs, we don't have to reveal the participants, which is a significant privacy benefit

### What does this have to do with account abstraction?
**The true breakthrough here is that through AA, we can finally use Schnorr signatures.** Ethereum itself only supports ECDSA.

In other words, Schnorr signatures can only be used by AA wallets.

## Prior art and why Schnorr+AA is better
My initial inspiration was mainly the [Schnorr verification hack](https://hackmd.io/@nZ-twauPRISEa6G9zg3XRw/SyjJzSLt9) that [Vitalik initially proposed](https://ethresear.ch/t/you-can-kinda-abuse-ecrecover-to-do-ecmul-in-secp256k1-today/2384). This enables AA wallets to verify Schnorr signatures on-chain for about the same gas cost as a regular ECDSA signature!

There are tons of MPC solutions, but in an AA future, where each account is a contract and can easily rotate keys, Schnorr is clearly superior to MPC because:
- It is simpler and easier to audit
- It requires fewer rounds of interactivity
- It is way easier to build flexible signature schemes such as threshold signatures (see [FROST](https://eprint.iacr.org/2020/852.pdf))

**Here's a breakdown of why AA + Schnorr is the best combo:**

| *Feature* | MPC | AA | Schnorr | AA + MPC | AA + Schnorr |
|---------|-----|----|---------|----------|--------------|
|Cheap to verify on-chain|✔|❌|N/A|✔|✔
|Key rotation|❌|✔||✔|✔
|Easy to audit|❌|✔||❌|✔
|No excessive interactivity (>2 rounds)|❌|✔||❌|✔
|Privacy (not revealing the signers)|✔|❌||✔|✔

**Note:** Schnorr signatures cannot be verified on-chain without account abstraction.

### Signature scheme research
We explored the following signature schemes:
- Naive aggregation: Schnorr signatures can be simply added together, but this scheme suffers from [the rogue key/key cancellation attack](https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures#na%C3%AFve-signature-aggregation)
- [MuSig1](https://eprint.iacr.org/2018/068): initially the library was based on it, but it requires 3 rounds of interactivity
- [FROST](https://eprint.iacr.org/2020/852): is currently used by [noot](https://hackmd.io/@nZ-twauPRISEa6G9zg3XRw/SyjJzSLt9) in a similar way, but it's too complicated for the purposes of a simple N/N multi-signature. FROST is designed for threshold signatures.
- [MuSig2](https://eprint.iacr.org/2020/1261): a two-round signature scheme - can be reduced to one interactive round thanks to pre-signing - **this is what Schnorrkel.js is using**

## What the grant is for
To further develop a JavaScript library that can produce Schnorr signatures that:
- Can be aggregated together to form N/N multisignature public keys
- Are cryptographically secure and do not suffer from rogue-key attack
- Can be verified via Vitalik's [proposed ecrecover hack](https://ethresear.ch/t/you-can-kinda-abuse-ecrecover-to-do-ecmul-in-secp256k1-today/2384)
- Doesn't require many rounds of interactivity

## Schnorrkel.js

Schnorrkel.js is a JavaScript library for Schnorr signatures with multi-signature (signature aggregation) capability.

So far, we managed to achieve the following:
- Thanks to [MuSig2](https://eprint.iacr.org/2020/1261), there's only two rounds, the first of which can be semi-interactive (preloaded); so essentially it acts like a **single-round multi-signature scheme**
- Produces signatures that can be cheaply **verified on-chain for less than 5k gas**, [thanks to Vitalik's ecrecover hack](https://ethresear.ch/t/you-can-kinda-abuse-ecrecover-to-do-ecmul-in-secp256k1-today/2384)
- Simple & easily auditable: the Schnorr signature scheme is [linear](https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures#so-why-all-the-fuss), which means that signature aggregation is mathematically simple and does not require the workarounds that MPC over ECDSA does (eg [homomorphic encryption](https://www.youtube.com/watch?v=HrTROcQNGnU), zero-knowledge proofs)

### Current progress
We have built the library to a point where it can sign [MuSig2](https://eprint.iacr.org/2020/1261) signatures with only one round of interactivity (plus one round of pre-signing which is to exchange public nonces).

Those signatures can be verified in Solidity and there's a test for this: https://github.com/borislav-itskov/schnorrkel.js/blob/main/contracts/SchnorrAccountAbstraction.sol and https://github.com/borislav-itskov/schnorrkel.js/blob/main/test/MultiSigTest.js

Furthermore, [SchnorrAccountAbstraction.sol](https://github.com/borislav-itskov/schnorrkel.js/blob/main/contracts/SchnorrAccountAbstraction.sol) includes a simple ERC-4337 smart contract wallet.

### Further development & budget
The proposed $18k budget will be used to:
- Further development of the library: rewrite in TypeScript, full test coverage and API ergonomics improvements
- Security auditing and hardening
- Rust port of the library
- Build a simple proof of concept ERC-4337 wallet app where you have to sign a transaction on two devices - mobile phone and desktop
- Prototype with one of the major AA wallets (one of: Argent, Safe, Ambire, Sequence)

Around half of the budget will go towards auditing, and the other half will cover approximately 5 months of 20 hours per week joint effort from the team to work on the library.

### Team

#### Borislav Itskov
My name is Borislav Itskov and I am a programmer and a Web3 enthusiast.

I studied cryptography at the Technical University in Varna, Bulgaria, but I dropped out during the middle of second grade to start working for a company in Varna called Devlabs. I've worked on various web projects mainly as a backend developer.

After about 8 years, I discovered smart contracts and became a Solidity developer. Along with Solidity, I rediscovered my passion for cryptography again, hence the library I worked on for the past month or so.

#### Cvetan Mihaylov
Cvetan Mihaylov is a software developer with almost ten years of experience in network engineering. Having switched to building software, he specialized in crafting back-end solutions in the last 7 years. Over the past year and a half he focused on blockchain and Web3 development, with a strong emphasis on Ethereum and other EVM-based blockchains. With an unquenchable thirst for all things tech, Cvetan is captivated by the immense potential of decentralized technologies and the boundless opportunities they offer.

### Security

The security of the MuSig2 signature scheme is already analyzed in the [MuSig2 paper](https://eprint.iacr.org/2020/1261). However, while the library tries to follow the paper as closely as possible, we believe that the best way to ensure it's security will be an external audit.

### Timeline
- May 2023: Schnorrkel.js v1 (TypeScript rewrite, full test coverage, more ergonomical API)
- Mid 2023: Schnorrkel.js v1 security audit
- Fall 2023: example integration with Safe
- Late 2023: Schnorrkel.rs: Rust port

We are open to discussing different timelines and engaging external contributors.