Discover more from Bankless Publishing
Zero Privacy—Zero Security; Intro to SUAVE | The DeFi Download
Privacy Chains; Flashbots' SUAVE Network
Dear Bankless Nation 🏴,
In this edition of the DeFi Download, Austin Foss picks up the Zero Knowledge (ZK) theme, continuing on from zkEVM powered rollups and moving to ZK enabled privacy on blockchains.
Are zkEVMs the endgame, or is there something next? Privacy is difficult to implement in blockchains perform operations on a known, publicly verifiable, state, but ZK cryptography can give us a verifiable public & private hybrid chain.
Afterwards, Jake and Stake gives us the down low on SUAVE, what Flashbots thinks is the future of MEV.
Thank you for continuing to support our as we look forward to bringing you more breakdowns of leading edge developments in the cryptocurrency ecosystem.
This is the DeFi Download ⚡️
Zero Privacy—Zero Security
Author: Austin Foss
In the last issue of the DeFi Download, titled Zero to One Knowledge: Comparing zkSync's Era and Polygon's zkEVM, we explored the essential concepts of ZK Rollups (ZKRUs) and zkEVMs; in this issue we will dive further into how ZK proofs (ZKPs) are used to provide privacy on public blockchains and can be further developed to give a privacy first approach to future ZKRUs.
The ZK in ZK-rollup
ZKRUs like zkSync Era and Polygon's zkEVM provide data availability layers, described in the previous issue, to make committing their proofs to the L1 cheaper and more efficient. If the data wasn't separated from the proof this would increase the gas cost per block as well as bloat Ethereum's state size.
This process does not leverage the full power of ZKPs, which is the ability to prove something without ever revealing one or more of the original inputs. These data availability layers do reveal those original inputs from the known public state of the blockchain.
The ability to withhold information about a claim while being able to guarantee your claim is correct is a new, fundamental, cryptographic primitive, whose applications are being discovered as we speak. For instance, the hypothetical claim that the address "anon.eth has 1 more ETH at block x than at block x-1", and never revealing who sent 1 ETH to anon.eth.
The First ZK Application(s)
Using ZKPs to advance scaling technology through projects like Loopring and now EVM compatible/equivalent ZKRUs will benefit every user of the Ethereum ecosystem by increasing the total bandwidth of the network, but that wasn't the first use case for ZKPs.
The phrase "zero-knowledge" was first used prior to blockchains back in 2007, describing a privacy focused "online password manager", but not at all related to ZKPs. "[T]he first widespread application of zk-SNARKs" was a privacy focused L1 blockchain called Zcash. A few years later ZKPs brought private transactions to Ethereum when the Tornado Cash project launched.
How to Hide in Plain Sight
For most people, it's sufficient to simply use a centralized exchange (CEX) as an intermediary to obfuscate the links between our different wallets by making a deposit from an externally owned account and then withdrawing to a different one from the CEX; but the CEX still knows which wallets are yours.
But using an L1 dedicated to privacy (like Zcash and Monero) gives you the option to achieve anonymity without resorting to a centralized, trusted entity like a CEX. Even those chains aren't perfect, and in some cases, organizations like Chainalysis can trace a specific user's transactions "ushttps://aztec.network/research-and-talksing simple heuristics".
On top of simple pattern analysis across the set of known users in a privacy pool, there are other ways you can accidentally give away your identity; such as sending a transaction from your residential IP address, and centralized Ethereum RPC endpoints, etc.
In many respects, blockchains seem to be antithetical to privacy: interacting with blockchains are gated by CEXs and the state of accounts and programs is public by default. But there are solutions.
UTXO & Account Models
A small but important nuance between L1s is how the blockchain's state is accounted for; Bitcoin uses an unspent transaction output (UTXO) format and Ethereum uses an account oriented model.
Due to the nature of account based models, everytime we send a transaction from an address that account is what is modified. When a Bitcoin transaction is made the owner of a UTXO signs the authorization and it is what's modified, producing new UTXOs, but a new UTXO's owner isn't easy to determine from the chain data.
This difference makes UTXO models more suited for privacy preserving applications due to this nuance.
Another factor that determines the security of privacy preserving technologies is what's called their anonymity set—each individual privacy solution's total number of unique users. If two anonymous users make deposits and a third makes a withdrawal then the anonymity set is three; either the third user is a new individual who was sent funds from user one or two or user three is actually an alias for user one or user two.
That's just the smallest anonymity set possible, and you can imagine how that scales up with thousands of users. As users make mistakes and give away their identity they "will no longer belong to the anonymity set."
After Tornado Cash was sanctioned by USA OFAC authorities, its anonymity set fell from about 1000 to about 100 users per week on main-net. This drop in the size of the anonymity set could potentially have something to do with why the Euler Finance hacker chose to return all the funds that they could, after having already sent funds through Tornado Cash. Perhaps Chainalysis or similar blockchain sleuths were able to heuristically determine who the attacker was.
"The zero-knowledge proof that proves the correctness of every transaction also proves that the encrypted data was correctly derived from the non-encrypted ‘plaintext’ data. But the plaintext is known only to the users that constructed their private transactions." - Zac Williamson, Aztec’s ZK-ZK-Rollup, looking behind the crypto curtain
This proof of a verified list of proofs resulted in the coining of a term "ZK-ZK-rollup". A little more than a year later Aztec Connect was launched. This iteration of the project grew its capabilities from just private transactions to private DeFi, allowing users to interact with protocols like Lido while still preserving their privacy.
A few months later Aztec launched their first usable iteration of a new domain specific language called Noir, a Rust-like programming language specific to the domain of writing private ZK applications.
Due to Aztec's privacy-first approach (as opposed to EVM-compatibility-first approach), developers are able to program private state changes within the Aztec rollup that aren't possible within the context of an EVM public state. Noir abstracts away the cryptographic complexities of the PLONK proving system giving a more familiar Rust-like experience.
In the previous issue, we touched briefly on the compilation tool LLVM and how zkSync leverages it to allow developers on their ZKRU to write smart contracts in Rust and C++. Not only are Noir programs compiled "to an intermediary representation (akin to LLVM), it is also compatible with multiple back-end proving systems including PLONK, Groth16, and Marlin."
Zero knowledge domain specific languages aren't new. Starkware has their own Cairo language, and up until October 2021 zkSync was developing a language called Zinc. In an announcement on a Uniswap V2 porting to zkSync the team also shared plans to switch to a Solidity first approach.
Noir, or other language abstraction, is required to interact with the private state of a zk-zk-rollup. Solidity, and other EVM specific languages, are simply not designed to perform these functions. Conversely, Noir is able to interact with both private and public states and can compile to a PLONK proving system. This means a Noir program can potentially be deployed on zkSync Era.
This past March, Aztec announced that they would be Sunsetting Aztec Connect, closing with a brief one-line description of what to expect next: "a decentralized general-use encrypted zkRollup." On May 4 another announcement was made to introduce "Aztec: the Hybrid zkRollup".
Hybrid refers to the ability for their ZK-ZK-rollup to interact with both a private and a public state.
Aztec Connect used the same UTXO model Bitcoin does except it’s encrypted, and the next iteration of the Aztec rollup will continue "and massively extends its scope and functionality." Fully functional smart contracts are implemented in this next iteration instead of the limited scope Connect could operate in.
Privacy by Default
Having a general-purpose, encrypted-by-default zkRollup is a tall order, but if executed correctly, such a rollup breaks the assumption that all blockchains allow anyone to trace our financial history.
Additionally, it overcomes the anonymity set problem to a degree by including any user who simply uses the rollup, not just the users who choose to use a privacy dApp on the rollup.
One problem is the issue of rollups. Today, all L2s on Ethereum use a centralized sequencer; it's the trade off we agree to in exchange for scalability, low gas fees, and ongoing development, but a even a centralized, privacy-focused sequencer is an obvious point of failure and a target for state regulators. Eventually, rollups will decentralize as the technology matures, but in wake of the US sanctioning of Tornadocash last year, this decentralization cannot come fast enough.
Maybe this is why Aztec states that the next generation of their rollup "will be fully decentralized at mainnet launch." Privacy by default, and decentralized from the start.
Intro to SUAVE
Author: Jake and Stake
It’s no secret that MEV is a centralizing force in blockchains. This “flywheel” effect occurs when a block proposer’s ability to collect rewards increases its ability to grow. The better a validator is at collecting MEV, the more validators they can create, leading to more MEV collection, and so on and so forth:
Validators → MEV → increased Stake → more validators → more MEV → …
The blockchain’s validator set will eventually converge on a few small parties that control an outsized proportion of the network, resulting in their ability to censor or otherwise control the network.
We’ve talked about how Flashbots’ MEV Boost has been able to stave-off the internet’s gravity-like quality of centralization by drawing hard lines between block proposers and a marketplace of builders, but problems still remain: block building is centralized.
The large majority of proposed blocks are created by only four block builders. As a result, these block builders have censoring power similar to that of proposers previously. In response to this centralization, Flashbots’ announced the creation of a new blockchain called SUAVE.
What is SUAVE?
SUAVE stands for Single Unifying Auction for Value Expression. It serves as an external mempool for unconfirmed transactions and what Flashbots calls “preferences”. SUAVE takes these preferences, creates blocks out of them, and then “executors” submit them to the appropriate domain (Ethereum, L2, or alt-L1). Let’s go through the lifecycle of a transaction.
Preference Expression and Execution
I think of SUAVE as a platform for MEV searchers where users and searchers submit transactions to SUAVE with instructions for how they want these transactions to be executed. These instructions are “preferences”, and they can encompass all kinds of modifications to the block. It could mean defining the contents of the block, the order of your transaction in the block, the slippage of a swap, or even all of the above across multiple blockchains.
Users express these preferences to “executors” by writing smart contracts to SUAVE that can granularly define their instructions. However, most users don’t need this level of specificity. Instead, they can simply submit common transactions to SUAVE.
Part of the expressibility of this MEV platform is the “bid” (payment) that users associate with their transaction. While users can submit positive bids to increase speed of settlement, users may instead opt to set negative bids and incrementally increase it over time—like a Dutch Auction. This allows users to capture the MEV that their transaction creates.
Suppose a user sets a transaction bid at -1 ETH that incrementally increases as time passes. At the beginning an executor would have to pay the user 1 ETH for the right to execute this transaction. Suppose 0.5 ETH of MEV can be captured using this transaction and the bid eventually increases to -0.4 ETH. Then the executor can add the transaction to their bundle, execute it, make a nice 0.1 ETH profit, and the user would receive 0.4 ETH in return.
Once the preference has been seen on SUAVE, a network of executors takes these preferences and generates bundles of transactions that satisfy the requirements specified. These bundles are collected and organized into partial or full blocks.
Settled Blocks Settle Payments
Executors are entities that fulfill preferences on SUAVE. They make sure the transactions are picked up by block proposers and settled on-chain.
But because preferences can vary widely, executors could be other MEV searchers, block builders, or validators themselves. A preference could be making sure a transaction is at the top of the block, a set of transactions are executed in a specific order, or some arbitrary state on Ethereum is updated.
Executors can participate in 3rd party MEV relays in order to get the preferences executed, but if they’re validators they can submit these full/partial blocks directly. Block proposers of various domains can query SUAVE for a block and submit that block to the chain. SUAVE allows anyone to be a block builder and it gives validators the ability to build their own blocks using SUAVE.
In the end, the user doesn’t care how their preference is executed, just that their transaction is settled. Once a preference is fulfilled on the specified domain, the user’s bid is paid to the executor.
Confirming Fulfillments with Oracles
Because SUAVE is its own blockchain, it doesn’t have direct secure proof of events not on-chain. As a result, oracles are a crucial component to putting everything together because they can inform SUAVE validators about what preferences are settled on another domain, like Ethereum.
But oracles do more than that. They make cross-domain MEV possible. There are particular challenges associated with cross-domain MEV because different blockchains settle at different rates.
SUAVE also plans to allow users to express risk tolerance for atomicity failure. In other words, users can place bids for partial fills or only reward executors that successfully settle both transactions.
In order to provide the necessary atomicity, oracles relay state information back to SUAVE and determine whether a cross-domain preference was fulfilled. No need for block proposers on each chain to peer into the state of the other. Once the transaction is confirmed, rewards for completing the preference are awarded to the executor(s).
Flashbots has decided to implement their own blockchain for this functionality in order to maintain neutrality to blockchains. Given the abundance of arbitrage opportunities across chains, SUAVE claims that it can provide better atomicity than being on a single chain alone.
In part, this is also a growth tactic for getting buy-in from blockchains because being chain-agnostic improves the attractiveness of participants from other ecosystems.
This system may also improve market efficiency, generally. For example, inverse transactions can be bundled together to reduce transaction costs. Imagine two trades on opposite sides of the same market: (ETH → DAI) and (DAI → ETH). Likened to COW Swap’s Coincidence of Wants, but generalized for various DeFi functions like lending.
Eventually, Flashbots plans to implement a variety of strategies to increase privacy and attract users like encrypted mempools and an orderflow auction like that of Rook. In the auction, executors will bid to complete user preferences with the best execution available. This mechanism serves to attract users to the platform.
This is going to be a big product release that could be very popular with market makers, users, and MEV searchers, but things are very much still in development. A lot of questions have not been answered, especially the details around mechanics. If successful, searchers will keep a lot of value on SUAVE and SUAVE block space will be quite valuable.
Project Releases 🎉
Hand-picked updates to help you understand the current state of the DeFi ecosystem
RocketPool Atlas Upgrade
Allow withdrawals upon Shanghai Upgrade
Lower ETH bond minimums to 8 ETH (3x capacity, 42% improvement over solo staking and 25% improvement over 16 ETH minipools)
Solo stakers can become rocketpool minipools without exiting the staking pool
A16Z releases OP Stack rollup client Magi
Written in Rust and not production-ready
Consensus client, not an execution client
Can sync to Optimism and Base testnets
1inch deploys to zkSync Era
DEX aggregator 1inch is now on zkSync Era
TransUnion partners with Spring Labs and Quadrata
Deliver off-chain credit scoring to DeFi and Web3 applications
The credit data will be provided at the request of the consumer.
DeFi apps will be able to better assess the risk they’re taking on by lending to certain consumers, and potentially give consumers more favorable terms when they opt to borrow via a blockchain-based platform.
Swell Network public beta launches on Mainnet
Swell is a non-custodial liquid staking protocol
Stake your ETH in exchange for a yield bearing liquid staking token swETH
Gated node-operators, but plan to move to permissionless eventually
Alchemy Partners with StarkNet
Alchemy now provides APIs that allow dApp developers to interact with StarkNet directly
StarkNet can tap into Alchemy’s developer community and users
Alchemy adds to its offerings, making it a more attractive starting point for developers
Flashbots Open Sources MEV bot framework
Artemis is Flashbots’ framework for creating MEV bots
Written in Rust for blazingly fast™ performance
Reusable components for interacting with blockchain infrastructure, monitoring, and alerting
Zapper adds onchain activity feed
Follow Ethereum transactions in real-time. Filter by topics, applications, and events.
Create lists of Ethereum accounts to track and follow
Discovery mechanism for recommended accounts to follow and trends
Includes Zapper-curated lists in collaboration with DegenScore
Stalk your favorite accounts more closely for even more alpha
🔥 and 🧊 tweets from across the DeFi ecosystem
BANK utility (BanklessDAO token)
With over 5,000 holders, BANK is one of the most widely held social tokens in crypto. So it bears asking, where are the best places to put our BANK to use? The five protocols below will allow you to deposit BANK in a liquidity pool and earn rewards. To get going, just click on the name, connect to the app, filter by BANK, and start earning passive income.
Balancer has two 80/20 liquidity pools, meaning that you are required to deposit 80% BANK and 20% ETH in the pool. There is one pool on Ethereum and another on Polygon. Once you’ve provided liquidity, you’ll receive LP tokens. Keep an eye out for opportunities to stake these LP tokens. There is nearly 500,000 USD in the two Balancer liquidity pools.
SushiSwap has a 50/50 BANK/ETH pool. As with Balancer, you will receive LP tokens, and while you can’t stake them on SushiSwap’s Onsen Farm yet, you may be able to in the future. Liquidity providers earn a .25% fee on all trades proportional to their pool share. The SushiSwap pool has a little over 100,000 USD in liquidity.
The Uniswap V3 liquidity pool is 50/50 BANK/ETH, and provides a price oracle for the Rari Fuse Pool. By depositing in the Uniswap pool, you can earn fees and help enable borrowing on Rari. This pool currently has over 500,000 USD in liquidity.
You can also provide liquidity to the Arrakis Uniswap V3 pool. The ratio is about 2/1 BANK/ETH. This pool is new, and only has a bit more than $6,000 in liquidity. In the future, you may be able to stake your BANK/ETH LP tokens within the protocol to earn additional rewards.