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.

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 that Vitalik initially proposed. 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)

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
• MuSig1: initially the library was based on it, but it requires 3 rounds of interactivity
• FROST: is currently used by noot 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: 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
• 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, 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
• Simple & easily auditable: the Schnorr signature scheme is linear, which means that signature aggregation is mathematically simple and does not require the workarounds that MPC over ECDSA does (eg homomorphic encryption, zero-knowledge proofs)

Current progress

We have built the library to a point where it can sign MuSig2 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 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. 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.