In today’s article, we continue the journey through public and private keys, blockchain algorithms, and Account Abstraction. Let’s focus on the complicated matter of ECDSA signatures and how to enable multisig transactions on Ethereum, shall we?

Have you ever seen Vitalik sad?

Or have you ever seen Vitalik angry?

It looks like Ethereum’s signature algorithm is quite exciting and not that straightforward even for its co-founder. In this blog post, we’re going to discuss why ECDSA is (in some ways) not that efficient, why Bitcoin already adopted another algorithm called Schnorr, and last but not least, I’ll show you what solutions are already available and developed by amazing Rumble Fish devs!

Let me do sign it for you!

For those of you who are not familiar with blockchain’s private-public key pair concept, don’t worry! Relax, grab a big cup of coffee, and let me guide you through this! Ready? Let’s go!
Every blockchain’s security, including Bitcoin and Ethereum, relies on cryptography and some brilliant underlying concepts. One of them is private-public key pairs which are used mainly for:

• authentication - to prove that the user knows the private key, which confirms their identity,
• encryption - to decrypt and read the message previously encoded, in other words - to read a secret message that only a private key owner can see. 

Private-public key pairs are asymmetric which means that with a given private key (think about it as simply as a number) it’s possible to derive the public key (the other number). However, it’s not feasible to reverse the process and get a private key from the public key. If you wonder why, take a look at our previous blog post, where I explained the magic behind elliptic curves and generating Ethereum addresses from private keys. To move forward I assume that ECC (elliptic curve cryptography) and ECDSA (Elliptic Curve Digital Signature Algorithm) acronyms already sound familiar to you. 

pov: ECDSA is a bad signature algorithm

As we’ve shown above, Vitalik himself believes that ECDSA is a bad algorithm. Let’s take a look at the reasoning behind this statement.
In Ethereum, ECDSA is used as the algorithm for creating and verifying digital signatures. This is to ensure transaction authentication, so we know the transaction was approved by the sender. ECDSA uses the SHA-256 hash function and the secp256k1 elliptic curve and does it for good reasons. Firstly, it is constructed in a special non-random way, which results in efficient and fast computations. It provides strong security while requiring relatively little computational power. Secondly, the secp256k1 curve reduces the possibility of potential backdoor weakness and is also used by Bitcoin, so was already adopted at the moment of Ethereum creation. Now, let’s see what the basic process of signing and verifying a message looks like:

Signing the message:

1. Generate a private-public key pair. Keep the private key hidden and share only the public key.
2. Calculate the message hash with a cryptographic hash function, e.g. SHA-256.
3. Sign the message with the private key. By signing I mean performing a series of mathematical operations on the message hash value and the private key, which results in a unique signature.
4. Transmit the message and its signature.

Verifying the signature:

1. Calculate the message hash the same way it was hashed within the signing process.
2. Recover the signer address from the signature and public key (for the sake of simplicity I’m not gonna explain all the math behind it - I encourage you to do your own research).
3. Compare the recovered address with the provided one - if they match, the signature is valid!

So far it’s all looking good, right? So what’s the problem with ECDSA? The chaos appears as soon as someone wants to create a multi-signature. Ekhm, excuse me, multi-what…? - you ask? Let me explain.

Multi-signatures - single problem

The Multi-signature Scheme is a concept that avoids a single point of failure and requires multiple signers to approve a transaction. This is great for splitting the responsibility of ownership of an address (and its funds) and can be shared between multiple people with different private keys. What's more, it’s possible to implement a k-of-n policy, so e.g. 2-of-3 means that only 2 signers (out of 3) need to approve the transaction for it to be valid (as shown below). This is commonly known as the threshold scheme.

There are already plenty of multi-signature wallets, like The Consensys multisig wallet, Safe, or Argent. Most often that kind of wallets use a smart contract that stores multiple signers' addresses and verifies the signatures one by one (naive multi-signatures). And that’s the core of the problem. Why? First of all, storing multiple signers’ addresses costs money (welcome to the blockchain!), and the same goes for sending and verifying multiple signatures. Every signature needs to be verified with a specified signer separately and computational power is the crucial aspect of the transaction cost. What’s more (and in some cases the worst) signers’ public addresses are exposed and can be easily used to check who (out of the signers group) approved the transaction and who didn’t. OK, so what about aggregating multiple signatures into a single one? Well, this might be a better approach, but aggregated signatures are currently slower than e.g. ECDSA, so there must be a tradeoff between speed and size (which on the blockchain means cost).

Bitcoin’s Taproot and Schnorr’s Signatures

Let’s jump out for a second to the Bitcoin Blockchain and look closer at one of the rare protocol updates, called Taproot. This BIP (Bitcoin Improvement Proposal) introduced several enhancements, including the Schnorr Signatures. Why do I mention this? We must realize that Bitcoin’s upgrades are extremely limited to keep the protocol stable and secure, so enhancements are deeply discussed, battle-tested, and significantly improve the network’s efficiency. So what is that Schnorr Signature?

It is a type of digital signature scheme that allows for signing transactions in a very efficient way without compromising on security even for multi-signatures. The algorithm itself isn’t new though, because originally it was described by Claus Schnorr in 1991. It wasn’t widely used before because it was protected by patent till 2008 (the same year Bitcoin was launched).
The primary advantage of Schnorr signatures lies in key aggregation. In a typical digital signature scenario, a single public key, message, and signature are involved, confirming that the owner of the public key signed the provided message. However, when multiple parties aim to sign the same message, like when spending from a multisig address, each must include their public key and signature. Consequently, if three parties wish to sign a message, the verification process entails three public keys and three signatures, leading to inefficiencies in computation and storage. Each node must conduct signature verification, a resource-intensive task, three times, and store three sets of signatures and public keys.

Key aggregation resolves this inefficiency by obviating the necessity for multiple public keys and signatures. Schnorr public keys and signatures can be aggregated so that, if three parties intend to sign a transaction, they can combine their public keys into a single one, using their respective private keys to sign the same message. Subsequently, they can combine their signatures into a single signature valid for the aggregate public key. A verifier needs only to authenticate a single signature and public key to ascertain that all three parties signed the message.

Signatures with benefits 

Key aggregation presents an opportunity to decrease transaction costs and enhance the scalability of the base layer, as signatures from multi-signature configurations occupy the same space in a block as those from single-party transactions. This aspect of Schnorr can be leveraged to decrease the size of multisig payments and related transactions (e.g. those within the Lightning Network channels).

Moreover, Schnorr signatures possess a crucial attribute of non-malleability. In the realm of digital signatures, malleability refers to the capacity of an attacker to alter a confirmed signature in a manner that retains its validity while authenticating a distinct message from the original signature. Such manipulation could lead to significant issues in cryptocurrency applications, potentially allowing a malicious actor to increase the transferred funds' amount or change the recipient.

Last but not least, Schnorr offers substantial privacy advantages. By enabling the obfuscation of a multi-signature scheme, rendering it virtually indistinguishable from a traditional single public key, Schnorr significantly complicates the task of differentiating between multisig and single-signature transactions through on-chain observation. Additionally, in setups involving n-of-m multisig, Schnorr makes it more challenging for observers to ascertain which participants did or did not sign a transaction.

Just do it!

Okay, that’s enough of the theory, let’s see what the practice looks like! As was written, the Bitcoin protocol already supports Schnorr Signatures and can be used alongside ECDSA. Unfortunately, the Ethereum blockchain does not yet, so this looks like a perfect opportunity for Rumble Fish developers to do, once again, some innovative stuff!

No, wait a sec. Let’s complicate things a bit so that it’s not too easy. Where would be the perfect place to use multi-signatures? Where can we find the need for a multi-owner wallet? Any ideas? Exactly, Account Abstraction! Take a look at our previous blog post about ERC-4337 to see what it is and let’s move to the coding part!

Let’s see what has to be done to achieve Multi-Schnorr-Signatures. 

1. Deploy MultiSigSmartAccountFactory and create Account Abstraction
   This is needed to interact with the blockchain and use the Account Abstraction concept. In our case though instead of a single Account Owner, there are multiple Schnorr-Signers Owners. 
2. Create Schnorr Signers and MultiSig Account Signer
   To utilize multi-signature features and be ERC-4337-compliant, the Schnorr Signer needs to be created out of an individual's private key.
3. Construct User Operation CallData and build User Operation
   As ERC-4337 specified, instead of standard transaction the User Operation needs to be created.
4. Initialize Multi-Sig Schnorr User Operation
   Crucial element of multi-signature mechanism. To be sure that the same transaction is approved by every needed signer, the desired Multi-Sig Schnorr User Operation is created. It contains such information as transaction data and each signer’s public addresses, one-time nonces, and signatures.
5. Sign the transaction by each defined signer
   Transactions can be signed by each signer in any order. There’s also no time limit or need for all of the signers to be online at once. 
6. Send the User Operation
   If a transaction is signed by each needed signer, it can be sent through the MultiSigSmartAccount contract. As needed it can be paid by ERC-4337 Paymaster. User Operation data can be signed and used only once by design!
7. Appreciate the beauty and simplicity of the Account Abstraction Schnorr Signatures solution. As simple as that!

But if you are curious about how it works under the hood or want to utilize this in your project, feel free to jump into Rumble Fish repositories:

• aa-schnorr-multisig
• aa-schnorr-multisig-sdk

That’s it! Today I’ve showcased the pain points and vulnerabilities of the ECDSA signature algorithm when it comes to creating multi-signature transactions. I’ve also taken you on a journey through Schnorr’s Signatures and how to tie them into Account Abstraction to create an effective multisig transaction on Ethereum. Stay tuned for future updates and feel free to reach out to our team if you have any blockchain-related questions!