SIGNING OUR WAY TO CHAIN ABSTRACTION
— All you need to know about Digital Signatures
“Sign here please.”
A phrase commonly used when you’re on bureaucratic missions such as registering a new address or closing a big deal. But signing goes beyond that and includes scribbling an unreadable line on a receipt held in front of you by a bored-looking waiter, as well as putting your mark under a birthday card.
Signatures go way back, way longer than any crypto bro could fathom, since their earliest reference point is, at best, the Roman Empire. The first evidence of signatures is found in a Sumerian clay table from 3000 before Christ.
We’ve evolved beyond relying on etching our scrawls into clay to signing digitally. In 2000, President Bill Clinton enacted the E-Sign Act, which validated electronic contracts, and since then we’ve all at least used DocuSign once.
Just like physical signatures, digital signatures establish a link between the thing signed and the individual. Cryptography forms the backbone of modern digital signature schemes and ensures that it’s almost impossible to forge another person’s signature. Unlike in real life, where people just draw random lines, and you can’t even tell what their name is.
Public Key Cryptography
With the rise of blockchains, signatures found yet another good use: as a tool to verify that a sender actually wants to execute a specific action. But let’s take a little step back and talk about public key cryptography.
The cryptography chains rely on also requires a private and a public key that forms a pair. Your public key is your wallet address, which allows you to receive funds. For NEAR wallets, it’s usually a [name].near Tied to that is a private key, which gives the owner the ability to decrypt messages and control funds in the wallet.
After all, modern key cryptography’s central premise is that the key used to encrypt data can be public, while the one used to decrypt it must be private.
Let’s say Bob sends Alice an encrypted message. He uses her public key to encrypt it, and then only Alice can decrypt it. The algorithms used for this are basically a one-way street. You cannot derive one’s private key from the public key.
On blockchains, we all interact like Bob and Alice. We send and receive transactions that are cryptographically signed, proving that we own the coins that we are spending. Despite the standard depiction of someone holding big bags, the actual “funds” aren’t in our hands. It’s just the private keys that give us access to them. That’s why they say, not your keys, not your coins.
Take Bitcoin. When you say you hold BTC, what you actually have is unspent transaction outputs (UTXOs), which the system tracks to establish how much you can spend. But that in itself warrants a whole separate post.
Moving on, not all blockchains rely on the same type of signature scheme.
Different Signature Schemes
What all signature schemes have in common is their reliance on mathematical problems that are difficult to solve.
The first scheme used was ECDSA.
ECDSA
It’s short for elliptic curve digital signature algorithm, a term that might trigger PTSD in people like me who’ve not been great at math. As the name suggests, it uses elliptic curves, which are a finite group of points on a curve where it’s easy to perform operations in one direction but not in the other.
It’s like stand-up paddling in a river. If you do it with the stream, you’ll get quite far. Anyone trying to go the opposite way, though, will quickly give up or fall off their board.
Since the problem is hard to solve, it requires heavy computation, hence a strong system. ECDSA has also found applications in other projects to protect anonymity, such as the Tor Project and the World Wide Web, where it’s used to encrypt DNS information.
The initial implementation of the scheme in Bitcoin, however, was partly flawed, as it allowed the altering of transaction identifiers by its signature. With the SegWit update, Bitcoin pivoted to include another popular signature type: Schnorr signatures.
Schnorr signatures
One of the issues with EDCSA is the lack of compression and verification in one; it’s at least two steps. Schnorr signatures promised to solve that for Bitcoin. First proposed in 1988 by Claus Peter-Schnorr, they were around for the launch of Bitcoin but still patented.
Schnorr signatures are provably secure and no third party can alter any valid signature to create another one valid for the same key. Additionally, Schnorr enables the aggregation of signatures into a single transaction, which offers privacy benefits and potentially frees up block space.
With the implementation of Schnorr, Nodes could verify batches of transactions instead of going through each transaction and signature one by one. However, since the SegWit upgrade introducing Schnorr to Bitcoin was a soft fork, it is still compatible with the previous signature types.
Moving on to chains beyond Bitcoin, Ethereum, the most popular smart contract platform, relies on yet another type of schema.
BLS Signature
Prior to the pivot to Proof-of-Stake, ethereum was also relying on ECDSA. However, since then, they’ve implemented Boneh-Lynn-Sacham signatures, which depend on a pairing of unique properties of elliptic curves. Named after their inventors, they offer a compact, efficient way to validate and authenticate a transaction in a network.
Another convenient feature of BLS signatures is that they offer robust security at a shorter length. The smaller the signature, the better when it comes to occupying blockspace. Similar to Schnorr, BLS signatures allow for the aggregation of signatures, paving the way for scalability increases.
In essence, signature schemes are quite important for blockchains. So, how does NEAR relate to all of this?
Recently, a new NEP has been published that would enable fast and efficient verification of BLS signatures, as well as zkSNARKS (a type of ZK proof) based on one specific elliptic curve called BLS12–381 (yeah, the same BLS as described above 👀)
What does this mean for NEAR?
You remember that NEAR is all about abstracting chains. Signatures play a big role in that. This update will make NEAR compatible with all the projects using the same elliptic curves for their signatures.
Another step toward Abstraction.
Or, as intern likes to say, putting blockchain where it belongs: in the orchestra pit, not on the stage.
Written by Near Intern / @NEAR_intern
About NEARWEEK
NEARWEEK is the ultimate destination for all things related to NEAR. As the official NEAR Protocol newsletter and community platform, NEARWEEK goes beyond journalism in order to actively celebrate, participate in, and contribute to the NEAR ecosystem.
NEAR Newsletter | Editorial (dapp)| Twitter
About NEAR Protocol
NEAR is on a mission to onboard a billion users to the limitless possibilities of Web3 with chain abstraction. Leveraging its high-performance, carbon-neutral protocol, which is swift, secure, and scalable, NEAR offers a common layer for browsing and discovering the Open Web.
NEAR Discovery | What is Chain Abstraction?| NEAR NDC | Twitter
