Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Aztec is a zk-rollup on Ethereum that aims to solve privacy issues: that is to say, it is the only Layer 2 built from the ground up that completely protects user privacy.

In order to understand the paradigm change of private transactions and the importance of establishing privacy directly in the network architecture, we must first discuss “why Ethereum is not a privacy chain”.

Ethereum: a public blockchain

You may have heard the term public ledger . It consists of two parts: account and balance .

The most primitive transaction on Ethereum is to send ETH from one account (address) to another account. The network records these transactions by increasing the balance of one account and decreasing the balance of another account-in other words, ETH is not actually “transferred”.

Let us look at an example in detail: snoopdogg.eth wants to send a transaction to cozomomedici.eth.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Just two businessmen

The following is the transaction process: Snoop first had 100 ETH, and then his account deducted 20 ETH. And Cozomo initially had 0 ETH, and then his account was credited with 20 ETH. Snoop’s final account balance is 80 ETH, and Cozomo’s is 20 ETH. The transfer is complete.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Schematic diagram of the ledger for ETH transfer transactions

We can see the transaction amount credited and deducted from each account on etherscan.io. The “ins” (transfer in) and “outs” (transfer out) records shown in the figure below are public and visible to everyone. Below is the recent transaction history of an ENS named twinkienft.eth.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

All the glorious deeds of ta are recorded here: the public transaction of twinkienft.eth!

You may ask: “Who is twinkienft.eth?” I don’t have a clue, but I can see all the transaction records of him! You go to etherscan.io to see, you can also observe all transactions recorded on the blockchain.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Right on the homepage of etherscan.io!

You can see that there is an obvious problem here: we can not only see all account transactions, but also their amounts, assets and parties.

This is actually the role brought by the public blockchain. Due to its public nature, public blockchains are auditable and verifiable.

But it also means that if someone’s privacy is leaked (either intentionally or accidentally)-we can view their complete transaction history.

Tracking public transaction data is big business: companies like Chainalysis and Nansen will do some sophisticated analysis to correlate various wallets and monitor their transaction activity, and make probabilistic assumptions about who holds what assets.

Imagine that every time you swipe your card to buy a croissant, you have to show your bank statement to the world. This is really silly, right?

This is the status quo of Ethereum.

Solution: Account encryption?

“Uh, okay,” you might say, “this is easy to solve, just encrypt the account, balance and holder.” Duh, idiot! How could I be so stupid.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

This is how I feel every day…

In addition to discussing how to implement encrypted accounts:

Please recall the ledger mentioned earlier. After encrypting the account and transaction, we will get:

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Seems to work

After encryption, how should the network check accounts to ensure that there is no double-spending or complicity in malicious acts. Facts have proved that it is very difficult to solve this problem.

Go back to the example just now. If Snoop and Cozomo need to make a transaction, then they must interact, because the network cannot help check whether they have made a valid transaction.

1. Snoop requests Cozomo’s encrypted account status

2. Cozomo sends encrypted status to Snoop

3. Snoop decrypts the status of Cozomo and confirms the balance before the transaction

4. Snoop sends an encrypted payment to Cozomo

5. Cozomo sends his latest encryption status to Snoop

6. Snoop decrypts the latest status of Cozomo and confirms the balance after the transaction (and Cozomo did get the amount he was promised)

This well-designed process has serious drawbacks: it is expensive, time-consuming, and you can only interact with one person at a time—both parties must also be online at the same time.

To make matters worse, when they ended a two-party conversation, neither party could persuade the rest of the world, they just verified one of their transactions with each other.

Is it not good to use notes to keep accounts?

But what if we reverse the attribution structure? Ethereum uses the account model by default, where the account contains the balance. In other words, check the account and you will get its balance information.

What if we change our way of thinking? For example, the holder of a certain asset (represented by note) is someone.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Account contains balance information vs. asset note deduced holder

Bitcoin uses this mode, called UTXO (unspent transaction output, unused transaction output). But don’t worry about what the term means, just treat UTXO as cash (bank notes).

Let us first think about why it is safer and more private to use cash for bookkeeping—or more accurately, more secure and more private than an account-based system.

It is safe because only the two parties who trade the cash know that its ownership has changed hands! And no one else in the universe will know.

You can think of the cash transaction model as a change in the ownership of an item (note), while the account transaction model is a change in the status of two accounts.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Icon: Change of ownership of an encrypted ticket

When an Aztec transaction is in progress, the network simply reassigns ownership of a given note instead of updating the account balance (increasing or decreasing the balance).

Why is this mode so useful? It turns out that encrypting a ticket is much simpler because you only need to write two things on it: how much the ticket is worth and who is its owner. Then when it changes hands, just erase the old owner’s name and write the new owner’s name.

Simple transfer on Aztec

So, what happens in a simple bill transaction?

Suppose Snoop has two notes with a face value of 50 ETH (total 100 ETH), and Cozomo does not have any notes in hand.

The two bills in Snoop’s hand need to be destroyed, and two new bills need to be created: a bill with a face value of 80 ETH is distributed to Snoop, and a bill with a face value of 20 ETH is distributed to its new owner Cozomo.

However, if the value of these bills must be disclosed, how can privacy be protected?

Hmm… they did not disclose this information, at least not. Of course, Snoop and Cozomo know the value of the assets they trade, just like a cash transaction, but they do not need to disclose it to the world.

In order to protect their mutual privacy, Snoop released a transaction with a lock. He knew that only Cozomo’s private key could unlock the lock. By analogy, this is a bit like putting this note in a small safe. Of course, they all know what’s in the box (20 ETH), so Snoop must believe that Cozomo will not shout on the roof: “Someone just transferred me 20 ETH!”

But in addition, the ticket whose ownership has been reassigned will be returned to a data structure that contains all the tickets that have been created-this is a Merkel tree hash, which I will briefly introduce below it.

In the eyes of network observers, what the state of the system will look like-the face value and owner of each bill are fully encrypted.

Good housekeeper

We know that Snoop destroyed two tickets, created two new tickets, and then passed one of the new tickets to his friend Cozomo. So how do we ensure that they will not conspire to do evil, such as double spending? What if Snoop destroys two tickets with a total value of 100 ETH and then creates two new tickets with a total value of 200 ETH? Or, do they directly create bills of any amount or size?

Recall these two steps:

1. Snoop destroyed two notes with a face value of 50 ETH and created notes with a face value of 20 ETH and 80 ETH respectively

2. Snoop transfers the 20 ETH bill to Cozomo

In order to ensure that no suspicious behavior occurs in the first step, all Snoop needs to do is to prove to the system (Aztec) that the two tickets he intends to create are equivalent to the two tickets he intends to destroy.

This is called a connection-split transaction, and this transaction conforms to this simple equation: A + B = C + D

Below is the brain burning part, keep up!

In order to prove that the transfer note (C + D) is equivalent to the transfer note (A + B, or 100 ETH), Snoop generated a zero-knowledge proof (ZKP) locally in his browser.

Using zero-knowledge proof, he can prove the equation A + B = C + D without revealing the value of any of their assets.

Then Aztec verified the proof and said: “Since this is a zero-knowledge proof, then this must be valid.” At this point, the smart contract destroys the two transfer-in notes, then generates two transfer-out notes, and The new transfer-out note is recorded in the note registration form as an encrypted commitment.

Proof of ownership

It is worth discussing how to prove the ownership of a bill in Aztec, which is similar to proof in Ethereum. How do you prove that you control access to an Ethereum address-by signing a message with your wallet.

So how do you prove that you can access a certain Aztec ticket? A very, very peculiar cryptographic signature is called zero-knowledge proof.

This proof says, “In the state of Aztec, a) there is a note of a specific value, and b) I own the ownership of this note.”

So how is the status of the Aztec system stored? It is stored in two Merkel trees:

  • One is the bill tree, which contains all the bills that have been created;
  • One is an invalid tree, containing all the tickets that have been destroyed

If you have a ticket in Aztec, it means that the ticket exists in the “receipt tree”, and there is no corresponding invalid ticket in the “invalid tree”.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

The “receipt tree” on the left is vibrant, while the “invalid tree” on the right is heartbroken. If the tree on the right could talk, it might say something like “I hate you.”

When we talk about “destroying” a ticket, this actually means adding an invalid ticket to the “invalid tree” instead of deleting a ticket in the “receipt tree”.

Realization of Private Transaction: Introduction to Aztec Privacy Architecture

Merkel tree diagram

In order to send those tickets that have proven to be mine, a brand new Merkel tree (and Merkel root) will need to be created. Once the Merkel roots of the “receipt tree” and the “invalid tree” are moved to the new value (in other words, the state of the system has been updated), these Merkel roots will be published on the Ethereum main chain, And the transaction will be deemed recorded.

Write at the end

I hope this article will give readers a deep understanding of why privacy is so challenging: we need to verify that transactions are legal and executed correctly without violating or exposing user data.

These unique limitations mean that the privacy protection architecture must be built from the ground up. Aztec is the only L2 built in this way-user privacy is protected through its core architecture and uses zero-knowledge proofs to maintain network operations.

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/realization-of-private-transaction-introduction-to-aztec-privacy-architecture/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-12-23 23:54
Next 2021-12-23 23:56

Related articles