Want to run a full node on Bitcoin? Well, first you must download the entire blockchain (upwards of 100 GB) and go through all of the transaction data to check its validity. Then, after “replaying” every transaction in a row, you’ll be left with a set of unspent transaction outputs (UTXO) which defines the current state of the Bitcoin chain.
Every major blockchain out there is utilizing some type of this model. Private cryptocurrencies such as Monero and Zcash change it up a bit by concealing the unspent outputs and tracking the spent amounts instead; Ethereum, the second largest public blockchain, has a more sophisticated “global state” system. But they, too, much like Bitcoin, require a new participant (validator) to download and verify every transaction to get a valid state of the network (that they know comes from a legitimate history).
MimbleWimble – a new, mysterious blockchain design – can significantly compress chainstates and, on top of that, grant privacy and fungibility to blockchain users. In this post, I’ll describe how.
A brief backstory
The origin story of MibmleWimble is fascinating and, one might say, quite Bitcoiny. The system – the inherently private and scalable blockchain protocol – was first introduced in 2016 by a pseudonymous author who used the name Tom Elvis Jedusor (the real name of Voldemort in the French adaptations Harry Potter books).
The term MimbleWimble itself is taken from Deathly Hallows. It’s a tongue-tying spell that, in the book, is used on professor Snape to prevent him from disclosing the location of Lord Voldemort.
By naming the protocol MimbleWimble, the author implies that the network, too, is deaf and can’t reveal sensitive details about transactions.
Tom dropped a link to his white paper on the Bitcoin Wizards IRC channel. Then he logged off, and, as far as we know, never came back. The file was then inspected closely by several researchers in the space (who concluded that the idea had merit) and a few months after that Andrew Poelstra, a mathematician at Blockstream, did a presentation on MimbleWimble at the Scaling Bitcoin conference in Milan.
Later that year, Ignotus Peverell, another Harry Potter character, showed up on the IRC channel announcing that he’d started implementing the MimbleWible protocol in the project called Grin (as you might have guessed, another reference to J.K. Rowling’s saga). He dropped a GitHub link inviting everyone to join.
Now the project already has a testnet and its technology, still very new, is being perfected constantly.
So how does MimbleWimble work?
Before I get into the specifics of how MimbleWimble does away with redundant transaction data, let’s quickly recap, in a hand-wavy manner, some of the basics of Elliptic Curve Cryptography (ECC). In the context of private and public keys, an EC is just an algebraic structure that outlines a curve with a set of predefined points.
As you might recall, we generate large strings of random numbers to use as private keys on Bitcoin and other major chains. To get a corresponding public key, from a private key, we multiply this secret value by a point on an Elliptic Curve.
So, if your private key is a, your public key is a*F (where F is a point on an Elliptic Curve). You can safely let people know the public key (they’ll actually use it to send you funds) as it is virtually impossible for anyone to reverse engineer their way back from a*F to a.
If we add another random string of numbers, let’s call it b, and multiply it by the same point on an Elliptic Curve (a+b)*F we’ll find that (a+b)*F = a*F + b*F. And this property is crucial for MimbleWimble.
In MimbleWimble, as opposed to Bitcoin, transactions are composed of homomorphic commitments (Pedersen Commitments) instead of actual values which means that blinding factors – random and long strings of numbers – are added to each input and output to obscure the real amounts.
Pedersen Commitments look like this r*D + v*F where r is a blinding key, v is the actual amount, and D and F are points on an Elliptic Curve.
So, if one bundles three inputs into a single output I1+I2+I3=O1, MimbleWimble replaces the amounts with (rI1*D+I1*F) + (rI2*D + I2*F) + (rI3*D + I3*F ) = rO1*D + O1*F. These sums are all that validators see; they have no clue about how many coins are being sent or received.
Being homomorphic these commitments allow MimbleWimble miners to check the validity of a transaction by doing math on the encrypted values. To ensure that no funds were created out of thin air, which is the only validity condition miners care about, nodes subtract the sum of inputs from the sum of outputs. If the result adds up to zero, that means that no fraud was committed.
This system of concealing values is called Confidential Transactions, and it isn’t necessarily new; it was developed by Gregory Maxwell for Blockstream’s Elements Alpha. MimbleWimble, however, builds upon the principles described by Maxwell and uses blinding factors to not only hide the amounts but, also, to prove ownership of the outputs on the network.
Here’s what I mean: suppose your friend Jane sends you 5 coins and you choose 27 (in reality, this would be a long string of numbers) as a blinding factor. This is the output you’ll end up with – 27*D + 5*F.
The result of the addition is in plain view for the entire network, you and Jane both know she sent you 5 coins, and only you, the person who generated the blinding factor, know the value 27. Only you can spend this output.
Now imagine you want to transfer these same 5 coins to Jack. This time you’ll have to reveal the blinding factor (27) so that the receiving party – Jack – can balance the input and the output.
This is what we get:
O (his output) – I (your input) = (27*D + 5*F) – (27*D + 5*F) = 0*D + 0*F
As you can see, the transaction adds up to zero which means that no coins were created or destroyed. But there’s one problem – you know Jack’s private key and can easily steal these 5 coins back.
To resolve this, MimbleWimble allows Jack to pick one more value and add it to the transaction. Let’s say he chooses 10:
O – I = (27+10*D + 5F) – (27*D + 5*F) = 10*D + 0*F
Now, our sum is no longer zero. We have an excess value which, in MimbleWibmle, is referred to as transaction kernel. It is a point on an elliptic curve that we will treat as a public key (to which Jack owns a private key 10). The validity of this pubkey is proved by the fact that the sum of inputs and outputs adds up to zero.
In a nutshell, MimbleWimble nodes only have to ensure that O-I gives them a valid public key and that the person who created the transaction knows the private key. That person, Jack in our example, is therefore required to provide a signature built with an excess value (10 in this case).
How does MimbleWimble compress data out?
What we understand so far is that after adding all outputs and subtracting all inputs we should end up with an excess value – a transaction kernel – which we will treat as a multisig public key. And since this is the only thing needed to ensure verifiability, we can assemble several unrelated transactions into one big transaction and then streamline it using the principle of simplifying equations. (Example: if 8+x = 8+y, we can simplify the equation to x=y)
Note: bundling transaction into one big transaction is called CoinJoin in Bitcoin. MimbleWimble “one-ups” this idea by allowing miners to combine transactions non-interactively.
Let’s say we have two transactions but an input in TX2 spends an output from TX1:
TX1:
TX2:
Now let’s combine them:
As I3 and O2 are identical, we can get rid of them: it won’t affecting our final sum.
After we’ve combined a few transactions in a block and performed this cut through, we’re left with this:
-
Block header
-
Remaining inputs
-
Unspent outputs
-
Transaction kernels (which include transaction fees, multisignature public keys, signatures built with excess values)
Already we’ve saved lots of disc space and contributed greatly to privacy (the original transactions are now indistinguishable), but it doesn’t end there. We can apply this principle to the entire MimbleWimble blockchain. Every single input on the network spends an output from some earlier block, so we can go to an extreme here an cut out all of the matching data (preserving the kernels which prove that no transactions were invalid, unauthorized or inflationary).
After this clean-up, our blockchain will consist of:
-
Block headers;
-
A set of unspent outputs;
-
Transaction kernels;
This is just a tiny fraction of original data but it’s enough to ensure public verifiability (remember, our transaction kernels are proving state legitimacy). Therefore, a new verifier doesn’t need to download tons of background data to learn the current state.
Conclusion
Everything about MimbleWimble is exciting: Its history, the way it’s being developed, and its future. The creators of the system seem to have found a way to provide both scalability and a high level of privacy which are thought of to be at odds in the world of blockchains. There’s no doubt in my mind that the concepts described by Tom Elvis Jedusor will ultimately float back to large networks such as Bitcoin and Ethereum.
Let’s wait and see how things pan out.
About the author
|
|
Ivan Kohut, co-founder and Chief Technology Officer (CTO) at Perfectial. Ivan Kohut is dedicated to bringing value to the business as a solution architect and technical adviser. He leads research and software development efforts through introducing industry best practices, overseeing the latest technology trends, heading the software architecture and tech-leads groups. Mr. Kohut brings over 12 years of experience in software engineering and managing the successful growth of the IT outsourcing company. He holds a Master’s Degree in Applied Mathematics from Lviv Polytechnic National University. |
