blog.zigzag.exchange Open in urlscan Pro
162.159.153.4  Public Scan

Submitted URL: https://blog.zigzag.exchange/zigzag-invisibl3-a-privacy-preserving-dex-bb335f17c0ce
Effective URL: https://blog.zigzag.exchange/zigzag-invisibl3-a-privacy-preserving-dex-bb335f17c0ce?gi=ffec86c73085
Submission: On January 24 via api from PL — Scanned from DE

Form analysis 0 forms found in the DOM

Text Content

Open in app

Sign up

Sign In

Write


Sign up

Sign In


ZigZag Exchange
Follow

Jul 4, 2022

·
8 min read
·

Listen



Save








ZIGZAG INVISIBL3 — A PRIVACY PRESERVING DEX


Harry Potter in his invisibility cloak

This post is a technical introduction to the design of our new app-specific ZK
Rollup called InvisibL3: an order book exchange that natively incorporates
privacy while preserving atomic swaps, allowing users to maintain anonymity
on-chain while leveraging the full scalability of ZK Rollups.


THE IMPORTANCE OF PRIVACY

Even though addresses on the blockchain appear anonymous to unfamiliar users,
they allow anyone to see all your transactions. Once the pseudonymity of an
address is tied to an individual, there is essentially nowhere to hide. While
existing solutions, primarily Tornado Cash, are great options, they lack a lot
of utility.

InvisibL3 will provide something completely unique. Our exchange will allow
users to anonymously trade assets, while simultaneously concealing the amounts
they are trading in a confidential manner. Our notion is that privacy should not
just be an option, but a standard when it is concerning transactions. A world in
which pseudonymous bank statements are publicly visible for anyone to browse
through is not a practical vision for the evolution of cryptocurrencies. Our
exchange is not only meant to rival the existing privacy solutions, such as
Aztec Protocol or Tornado Cash, but also the traditional centralised and
decentralised exchanges. Some of the benefits of a private exchange are:

 * Allowing institutional traders to enter DeFi, as privacy is one of their main
   concerns (legally or otherwise)
 * Helps mitigate the “bad” MEV we are used to in the AMM mode, such as sandwich
   attacks
 * Allowing professional traders to keep their strategies private


A PRIVACY DEX WITHOUT COMPROMISING ON SECURITY OR SCALABILITY

The question is how to achieve privacy on a permissionless exchange while
preserving security and scalability. Probably the simplest answer that comes to
mind is leveraging the power of ZK proofs to prove that a state transition was
executed correctly without revealing any of the inputs (amounts or addresses).
Ultimately, that is not a big improvement over centralised exchanges. Instead of
trusting them with your funds, you would be trusting another centralised party
to keep your data available and private.

The second option is to design a system in such a way that all the hidden
transactions are public: amounts or senders can’t be seen, unless the correct
private keys are provided. This allows anyone to reconstruct the state and with
their private keys create proof that they indeed own their funds.


HOW ARE FUNDS HIDDEN?

Hiding your funds requires you to make a commitment to the amount you are
trading and like all other commitment schemes this needs to be both binding
(cannot be revealed to a different value later) and hiding (does not reveal
anything about the data being hidden).

A common choice for this could be a hash function, but InvisibL3 will use
something called Pedersen commitments instead, which have the additional
property of being additively homomorphic:

> C(a + b) = C(a) + C(b)

We will see why this is important later.

To construct these commitments, we multiply an elliptic curve point by the
amount we want to hide. Don’t worry, if you’re not familiar with elliptic
curves, all you need to know is that from x*G it’s very hard to find x, where G
is a known generator point.

However, because the amount a is always in a given range, we need to construct
the commitments as follows:

> C(a) = xG + aH

where x is a random blinding factor known only by the owner to prevent someone
from brute forcing all the common amount values and finding the one you sent.


HOW IS YOUR IDENTITY HIDDEN?

To hide your identity, a feature called subaddresses (popularised by Monero)
will be constructed. Each user starts with a set of two private keys — a private
view and spend key — and as the names suggest one will be used to find or
disclose the notes owned by the user and the other to spend them. From the
private keys a user can arbitrarily generate many subaddresses that cannot be
linked back to the original address and use those subaddresses to interact with
a market maker or another user.

Though, to prevent multiple notes being sent to the same address or having to
generate a new address every swap (which might reveal how many swaps the address
is making and could be used to identify larger market makers or institutional
traders), we also add so-called one-time addresses.

Instead of sending a note to the actual address, the sender generates a random
one-time address with a secret random seed, shared privately between the user
and the market maker. The user can then prove they own the note at the one-time
address with their private keys without disclosing their address or even their
subaddress.

More technical details on how we will work with subaddresses and one-time
addresses can be found in appendix A.


WHAT IF I LOSE MY PRIVATE KEYS?

Generating new notes with new addresses for every swap is unnecessarily
troublesome, so in practice the wallet provider and the private exchange (us)
will store your data in encrypted format so that you can easily retrieve your
notes using your private keys.

However, this does not mean you are relying on a third party to make that data
available. All the transactions and corresponding information needed to recreate
the state and find notes addressed to you are stored on chain as calldata and
can be retrieved using your private keys.

See appendix B for details on reconstructing commitments.


HOW DOES THE SWAP HAPPEN?

The most important part now is that the swap happens in a way agreed upon by
both the market maker and the user. Let’s look at an example swap. Say user A
wants to swap X amount of ETH for USDC. The user must first prove that they own
notes with amounts sufficient to make that swap. This is where Pedersen
commitments become useful.

Let’s say C1, …, Cn are the input notes user wants to spend and Co1, …, Com are
the output notes user is producing. Because of the homomorphic nature of these
commitments, we can easily check that the sum of input notes is equal to the sum
of output notes without revealing the amounts. In practice there is an extra
step of producing intermediary commitments to make the sum equal zero, but this
is not needed to understand the general architecture. See appendix C for details
on verifying commitment sums.

When making a swap you provide the hash of the inputs: the amount you want to
trade, the input and output asset type and asset price, as well as something
called a return address signature. The return address signature is what links
the maker and taker transactions together. This allows you to prove that you
know the private key of the one-time address generated by the transaction
private key (a random seed shared by you and the market maker) and prevents
either the market maker from sending your funds to some arbitrary address they
control or you from providing the wrong address by accident (removing the need
to quadruple check if you typed in the right 64-character hex string). The
transaction hash is then signed with the private keys of the input notes being
spent (and the intermediate commitment private key from appendix B) to prove
everything is in order.


SUMMARY AND CONCLUSION

To sum up, each swap consists of two transactions (maker and taker), where the
swap will only pass as valid if:

 1. the input notes exist in the state;
 2. the input and output notes sum to zero for both transactions;
 3. both parties signed the expected transaction hash with private keys
    corresponding to the notes being spent;
 4. the tokens and amounts being swapped match the counterparty signature;
 5. the destination address matches the return address signature.

The first one to three output notes will usually be sent to the market makers
filling your order, one note will be sent to the exchange as a fee and one will
be the refund sent back to you.

If you’re curious about existing technologies that have fuelled our research and
this blogpost, we suggest taking a look at the original Monero whitepaper and
the original ZCash whitepaper.



Be sure to follow us on Twitter (ZigZagExchange and ZigZagLabs) for more updates
on our development. Also join our Discord to talk to the team and ask any
questions that are on your mind.




APPENDIX A) SUBADDRESSES AND ONE-TIME ADDRESSES

Each user starts off with a set of two private keys: a private view key (kv) and
private spend key (ks) from which main public keys are generated:

> Kv = kv*G and Ks = ks*G

User then generates his subaddress private keys like so:

> ksi = ks + H(kv, i) ; kvi = kv*(ks + H(kv, i))

and the corresponding public keys Ksi and Kvi as above.

For the calculation of the one-time address the sender and receiver share a
private transaction key r (a random seed calculated using the FSH on the private
inputs).

The sender knows one of the receivers’ addresses ((Ksi, Kvi) pair) and can
calculate the one-time address as:

> Ko = H(r*Kv)G + Ksi

The user can then calculate the private key for that address as:

> ko = H(r*Kv) + ksi

And use said private key to prove that they indeed own that note


APPENDIX B) RECONSTRUCTING COMMITMENTS

When spending a note besides your private keys you also need to know the amount
and blinding factor of the commitment to be able to reconstruct that note. Below
is a scheme describing how these are calculated, so you can always retrieve the
notes addressed to you.

Sender uses the transaction private key r and senders Kv to construct:

 * blinding factor;

> x = H(“commitment_mask”, H(rKv))

 * hidden amount;

> Ah = a XOR8 H(“amount_mask”, H(rKv))

 * rG, rKv, Ah.

Along with every transaction on chain rG, rKv and Ah are provided for the
receiver to be able to recreate the commitments.

Receiver receives rG, rKv and Ah:

 * user first uses the private view key to check if rG * kv == rKv; if so, the
   note is addressed to user;
 * user can then calculate the blinding factor;

> x = H(“commitment_mask”, H(rKv))

 * and amount.

> a = Ah XOR8 H(“amount_mask”, H(rKv))

Therefore, the note:

> C(a) = xG + aH


APPENDIX C) VERIFYING COMMITMENT SUMS

The sum of input commitments is:

> C1 + … + Cn = x1G + a1H + … xnG + anH = (x1+…+xn)*G + (a1+…+an)*H

And the sum of outputs:

> Co1 + … + Con = y1G + b1H + … ymG + bmH = (y1+…+ym)*G + (a1+…+bm)*H

Where

> (a1+…+an) == (b1+…bm)

But

> (x1+…+xn) /= (y1+…+ym)

So

> (C1 + … + Cn) /= (Co1 + … + Com)

To make the sums equal we need to produce intermediate commitments for every
input note, such that the new sum of blindings matches the output blindings:

> C’i = x’i*G + a*H and (x’1+…x’n) == (y1+…+ym)

and

> (C’1 + … + C’n) == (Co1 + … + Com)

The differences zi = (xi — x’i), referred to as the intermediate commitment
private keys are than included in the signature to prove that the amounts in Ci
and C’i are the same.

Zigzag
Dex
Privacy


47

47





47






MORE FROM ZIGZAG EXCHANGE

Follow


ZigZag is a native, easy-to-use, reliable, fully secure and low fee
Decentralized Exchange built on ZK Rollups. https://info.zigzag.exchange

Jun 24, 2022


ZIGZAG 的代币经济学和 IDO 详细信息

ZigZag (ZZ) 是 ZigZag Exchange 多链生态系统的 ERC-20
治理代币。代币持有者将通过社区主导的决策过程以及在我们新成立的金库中管理资金来塑造 ZigZag 交易所的未来。
我们的使命仍然是通过革命性的零知识证明创建具有用户体验的去中心化交易所,与现有的中心化交易所没有区别。由于 ZigZag 交易所的做市商提供从中心 …

4 min read




4 min read




--------------------------------------------------------------------------------

Share your ideas with millions of readers.

Write on Medium

--------------------------------------------------------------------------------

Jun 24, 2022


ZIGZAG’S TOKENOMICS AND IDO DETAILS

ZigZag (ZZ) is an ERC-20 governance token for ZigZag Exchange’s multi-chain
ecosystem. Token holders will shape the future of ZigZag Exchange with a
community-led decision making process, as well as managing the funds within our
newly formed treasury. Our mission remains to create a decentralised exchange
with user experience…

4 min read




4 min read




--------------------------------------------------------------------------------

Mar 28, 2022


EXCHANGE COINS WE ADMIRE, AND WHY

These seven coins helped leading exchanges bootstrap trading volumes, enriching
holders, operators and investors. Here’s a comparison of how they work. When the
narrative of the “utility token” caught fire in 2016, lots of ICO tokens
followed with little utility. Today, the category is very real, and it’s
dominated by…

Ethereum

19 min read



Ethereum

19 min read




--------------------------------------------------------------------------------

Feb 15, 2022


ZIGZAG’S VISION FOR ETHEREUM LAYER-2 DEX

How zkSync and StarkNet can unlock P2P trading without compromises. One year
ago, the ZigZag team began reimagining what they saw on Uniswap. Yes, to trade
without lengthy onboarding was revolutionary, harkening back to the days of
EtherDelta, but Uniswap’s UI lacked… information. Without an order book, trade
log, or…

Ethereum

4 min read


Ethereum

4 min read




--------------------------------------------------------------------------------

Feb 2, 2022


HOW TO PROVIDE LIQUIDITY WITH ZIGZAG MARKET MAKER

Getting setup as a liquidity provider has never been easier with this simple
bot. Exchanges need liquidity, and they’ll pay token-holders to provide it — but
the relationship isn’t exactly symbiotic. Until recently, becoming a “liquidity
provider” meant giving up control of your coins to a pool, or writing
sophisticated market-making software on your own. Is there a better way to
crowdsource market depth?

Ethereum

4 min read



Ethereum

4 min read




--------------------------------------------------------------------------------


RECOMMENDED FROM MEDIUM

Alexander Miles

in

Anoma

ANOMA COMMUNITY UPDATES: MAY 2022



Nicola Di Marco

in

PieDAO

ANNOUNCING THE 100 VEDOUGH HOLDERS ZSU 🧟 NFT WINNERS



qBuckz

MASA FINANCE $MASA AIRDROP COMPLETE GUIDE



Beosin

BEOSIN HAS COMPLETED SECURITY AUDIT SERVICE OF CRAFTING



HostPapa

WHAT INTERNET COOKIES ARE AND HOW THEY CAN HELP YOUR BUSINESS



Dona Mara

in

I’m #HAPI

UNITY COMPASSION SOLIDARITY. YOU CAN HELP UKRAINIAN PEOPLE!



SparkPost

HOW TO BULLETPROOF YOUR EMAIL IN 2017!



HostPapa

WEBSITE SECURITY — WHY SHOULD YOU CARE?



AboutHelpTermsPrivacy

--------------------------------------------------------------------------------


GET THE MEDIUM APP




ZIGZAG EXCHANGE

358 Followers

ZigZag is a native, easy-to-use, reliable, fully secure and low fee
Decentralized Exchange built on ZK Rollups. https://info.zigzag.exchange

Follow



MORE FROM MEDIUM

Ann

in

Crypto 24/7

THESE NEW DEFI PROTOCOLS ARE FREAKING IMPRESSIVE



Dr_jackal

TUTORIAL — HOW TO INSTALL A FULL NODE ON THE SUI NETWORK — DEVNET



BountyBase

WHAT IS STARKNET: POST-QUANTUM SECURE LAYER-2 SCALING SOLUTION



Ignacio de Gregorio

WHY IS CRYPTO EXPLODING NOW?



Help

Status

Writers

Blog

Careers

Privacy

Terms

About

Text to speech

To make Medium work, we log user data. By using Medium, you agree to our Privacy
Policy, including cookie policy.