Operation of privacy pools, uncontrolled privacy, and the role of centralization
“Building privacy solutions without considering Tornado Cash is impossible”
Sonya Sun
May 4
“Building privacy solutions without considering Tornado Cash is impossible”
About the background
Almost five years ago, I became acquainted with the EVM ecosystem and have since been working on projects that contribute to its development. Initially, I simply participated in various fintech schools and fintech Olympiads. Interestingly, when I signed up for these Olympiads, I had no idea they were related to cryptocurrency. It’s quite possible that had someone told me directly, I wouldn’t have been interested in such activities because “fintech” was a more popular and trendy term at the time. People tried to associate everything with it, including crypto events.
Over the years, I have worked on several projects. Essentially, I have been working with the same group of people, as while the projects change, the team and its core members remain constant. For instance, I worked at POA Network. Its main achievement was launching the first cross-chain bridge into production, allowing for the transfer of tokens. Nowadays, there are many different bridges utilizing various technologies, but back then, it was all just beginning. I contributed to the development of the bridge between POA Network and Ethereum Mainnet.
After POA Network, I worked at XDAI Chain—now known as GnosisChain since the project transitioned under the management of Gnosis. There, we conducted significant experiments and worked on tasks related to the development and maintenance of sidechains and cross-chain bridges that support tokens, messages, and so forth.
We developed and researched Proof-of-Stake, even attempting to create our own. Eventually, XDAI Chain transitioned to Ethereum Proof-of-Stake with its Beacon Chain. The area in which GnosisChain currently operates was my focus for a long time.
About enhancing programming skills
I have a rather lengthy history specifically with programming, separate from my work in crypto. I started programming a long time ago, back in my school days—I was coding semi-professionally and participating in Olympiads. Towards the end, I began engaging in more industry-oriented Olympiads, hackathons, and the like. After high school, it was time to choose a university, and I wasn’t keen on attending a typical institution, spending time on uninteresting subjects and listening to uninspiring individuals.
I decided to enroll at Innopolis University. Back then, it was a little-known and adventurous place; now, it’s a well-established institution that’s widely recognized. While I didn’t acquire blockchain development skills at Innopolis, I am grateful for the four bachelor years for other opportunities they provided. For instance, I had the chance to read all literature and work on various projects entirely in English.
"This definitely significantly simplifies life and a career in crypto and beyond." There were also plenty of opportunities to interact with interesting people, engage in projects that fascinated me without struggling in other subjects. All of this came with other cool opportunities: working on pet projects, interning, or part-time working at foreign companies—there was time for self-education, participating in hackathons, and other projects.
Regarding employment, my situation is probably unique. Typically, those who work in crypto had only worked in the non-crypto world before. In my case, 90% of all my professional experience during and after university is all about crypto, with the remaining 10% being my time working in other places. However, people often enter the crypto space from different sectors: fintech, large Russian corporations, and so on. But my journey is entirely different.
Currently, there isn’t a single task or direction to which I dedicate 100% of my time. Usually, there’s smart contract development, which I personally handle, and there are more product-oriented tasks that require discussions about new features.
There are also significant activities related to events, conferences, and hackathons. Of course, there are tasks not related to smart contracts but to backend components: reviewing pull requests, changes to components, UI, SDK, sequencer, and so on.
About uniqueness of Blockscout
Currently, I’m working on two independent projects—Blockscout and zkBob. Blockscout has been around since before I learned about crypto. It’s probably one of the very old projects that has survived everything and still exists to this day. Just open their history on GitHub—it’s quite incredible.
"It has a bit of everything; various individuals have committed to it, and many people have worked on it. That’s the power of significant open-source projects. A large number of people are willing to contribute to them at different stages, and all this history is public and can be studied. Blockscout now has a substantial roadmap for the upcoming years—a large team is diligently working on its development and support in partner networks."
Most people have heard about Blockscout one way or another because it’s the top open-source blockchain explorer. Of course, that’s if we don’t remove the “open-source” qualifier. Otherwise, the top one would be Etherscan, which, by the way, many dislike due to its closed-source code. Consequently, many new EVM-compatible networks emerging in web3 can’t afford to connect to Etherscan. That’s precisely why we started developing Blockscout.
It’s still actively evolving: we invest many resources in it, launch hosting versions for different EVM networks, and provide people with instructions on how to launch the explorer in open-source mode for their networks, on their infrastructure, without paying launch fees.
About the uniqueness and ideas behind zkBob
I work full-time at zkBob. To avoid confusion, let me explain: Bob is a USD-pegged stablecoin we are quietly building, and we position zkBob as functional privacy for this stablecoin. You could say that zkBob is a composite of two sub-projects.
It’s evident to everyone that some form of privacy must exist on the blockchain. After all, we are accustomed to a degree of privacy in traditional finance and banking infrastructure—we take it for granted.
"We expect our data to be private. However, most of our blockchain transactions are public, even though the addresses aren’t tied to individuals’ identities. This situation creates a myriad of problems, acting as a significant barrier to the mass adoption of blockchain and the infrastructure built upon it. That’s why a certain level of privacy is a crucial component necessary for the further development of blockchain, encouraging more and more people to start using it."
When it comes to comparing different stablecoins, it’s usually hard to find features in one that aren’t present in another; they are all very similar. Therefore, we decided to create a stablecoin with a killer feature in the form of optional privacy. With this feature, the stablecoin could be used not only publicly and on-chain in DeFi, AMMs, etc., but also for sending private transactions. We are trying to establish partnerships and find interesting use cases for these private transactions and the product itself.
"Currently, the primary use case for which people use zkBob is salary payments. At zkBob and Blockscout, for instance, we pay our employees and contractors, using Bob for irregular payments. We also try to explain to people why using Bob might be interesting and beneficial. When discussions turn to salaries, payments in stablecoins are expected—because it’s better than volatile tokens. However, the privacy of stablecoins isn’t always addressed."
To achieve some level of privacy for salary payments, many people use CEX. But over the past six months to a year, numerous questions and concerns have arisen about centralized exchanges, particularly regarding the security and use of funds. The issues that occurred with FTX and other exchanges are due to the specific jurisdictions of these exchanges. That’s how zkBob came into existence. We suggest people use it for salary payments, organizing donations, fundraising, and similar activities.
About using zkBob for private transactions and donations
Many individuals employed by crypto companies and DAOs receive their salaries—whether regular or irregular—in some form of stablecoin, most often in USDC, USDT, or DAI. Employees are asked to provide a wallet address in their invoice, and the payment in stablecoins is sent to this address from a multisig wallet, another wallet, or an exchange. Clearly, it would be inconvenient for an employee to provide their primary wallet address in these invoices, resulting in a complete lack of privacy and a host of discomforts. Everyone would be able to see the history of their transactions, creating risks from multiple angles.
Before zkBob's advent, my salary payment process—and I believe many others’—worked similarly. Instead of providing your primary wallet address each time, you either create a one-time wallet to receive the stablecoins and then transfer them to a CEX, or you directly provide a deposit address from an exchange. Most exchanges allow the generation of multiple addresses, so you can provide a new address each time to maintain some level of privacy. Then, you withdraw the funds to your primary wallet, making it harder to trace the transactions while simplifying and securing your financial life.
Employers can pay contractors, employees, and teams from their account on a CEX, sending money to different wallets. zkBob can be implemented in the same way. Funds will arrive from a wallet on, say, Binance, and no one will know who sent them. Moreover, if team members don't know each other's addresses, a level of privacy is maintained.
The first version of zkBob has been in production for over six months. During this time, it has undergone many updates. We specifically use it for payroll solutions, as do several partner teams we've convinced of zkBob's benefits.
People use it for various use cases. Some use it for P2P transfers between friends, while others use it for donations. Currently, two pools are deployed on Polygon, and recently on Optimism—for $BOB tokens. We plan to expand into multichain in the future, and pools for other tokens will likely be introduced. Since $BOB was created at the contract level specifically for zkBob, there are integration points that allow for smoother operation, but new pools for other tokens on different networks will emerge either way.
The layer gradation constantly sparks debates, discussions, and sometimes even flame wars. It’s challenging to categorize zkBob definitively. In a way, it acts like an app-specific rollup, specially designed for transfers and privacy. We are not a rollup like Optimism, Arbitrum, zkEVM, or similar. We are not a full-fledged EVM rollup.
If people have funds in an L2 solution, they can deposit into zkBob, essentially moving to the next level. They can transact within the zkBob environment, make private transfers, send/receive salaries, and other payments, and then withdraw back to the L2 solution. In a way, understanding is simplified if you consider zkBob as an L3 rollup.
About the use cases in zkBob
In the current implementation of our appchain, the only function available is facilitating private transactions with $BOB. We'll see what requests for additional features will arise. Some have attempted to integrate privacy appchains with DEXs, which can generate yield.
There are questions about whether people need this at all and whether it's worth developing. Perhaps it makes sense to focus specifically on the privacy aspect and develop it further since that's the primary reason people use zkBob—not to swap within a private pool or to earn on funds invested in a pool.
There's also the possibility of bridging $BOB between different networks and then depositing it into a pool on another network. Currently, there's no mechanism that can directly send $BOB from a zkBob pool on Polygon to a zkBob pool on Optimism. There hasn't been a clear request from users for such a feature, but we are gradually exploring this direction. If it's indeed necessary, we'll devise such a mechanism. To make a cross-chain transfer now, you need to combine several operations: withdrawal, bridging using traditional bridges, and then depositing into the second network.
Within our app, there's convenient integration with LI.FI, a bridge and DEX aggregator. Without leaving the app, users can withdraw, open a widget, swap, send money to another network, change the network in the chain selector, or at the top of the app header, and deposit into the new network. Of course, this process takes some time and additional resources, but people use it.
Currently, zkBob's bottleneck is the absence of certain networks and tokens that people would like to work with.
Perhaps someone doesn't want to use $BOB due to internal considerations or simply because they dislike Polygon. But they might really like Arbitrum and hold $ARB, which they want to privately send within Arbitrum. There is a demand for adding more networks, and we are currently working on this.
We also frequently receive reports about typical technical problems encountered by Ethereum wallet owners: seed phrases, passwords, and account recovery. Often, people don't understand what to do when a transaction error pops up—they clicked the "send transaction" button, but it doesn't go through. Panic ensues: did the money get sent or not? We try to fix such errors, address niche problems, improve UX, redesign UI, change tooltips, and simplify onboarding. That is, we explain how to properly work with seed phrases, create accounts, and recover accounts.
Initially, all changes will be on Optimism and Polygon. Understandably, we are building relationships with other networks as well. We are interested in deploying on our native Gnosis Chain and on Arbitrum. But everything needs to be done in order of priority. Indeed, all popular L2 solutions will definitely be introduced, including Polygon zkEVM.
About centralization as a crucial part of product functionality and uncontrolled privacy
From an architectural standpoint, our appchain resembles Optimism or Arbitrum. Currently, there's a single sequencer assisting users in processing and including their transactions. This design choice is made for several reasons, including user privacy. All transactions sent by a user are trustless. Users merely sign a message, for instance in MetaMask, and pay a fee in the tokens they are sending within the pool, in this case, $BOB. A high level of privacy is achieved since transactions are sent from a centralized relayer, eliminating the need for users to execute all transactions personally from their wallets. Consequently, transactions can't be traced back to the sender.
While we are advocates of privacy, we do not support uncontrolled use of privacy or projects that champion this cause unequivocally. Uncontrolled privacy—where there are no limits, AML, or optional KYC—is risky. Privacy is crucial, but it should exist with constraints on its use, such as limits on deposit, transfer, or withdrawal amounts. Some form of AML or KYC solution should be implemented.
Such solutions are possible with a centralized sequencer or, as we also call it, a relayer. We are exploring how to operate it in a more trustless mode. For instance, we currently use soulbound tokens in the form of NFTs for KYC, which can be obtained on Binance. There are also various solutions, like Polygon ID, that can provide identification privately using zkSNARKS, which we are considering.
There are also solutions regarding AML and wallet screening. Typically, we use the TRM API for AML checks, but there are more advanced solutions that allow wrapping these checks within snarks, making the process less centralized.
Once we figure out how to decentralize these aspects while maintaining limits, checks, and optional KYC, we'll consider decentralizing the sequencer.
There are several possible models: having multiple sequencers rotating based on consensus, or a mechanism where users choose the relayer, not the sequencer, under certain circumstances. If something goes wrong in the network and the centralized sequencer stops responding or transmitting transactions, effectively initiating total censorship, users can act as temporary relayers to process their own and others' transactions.
Decentralization for its own sake isn't valuable to many. It's a popular topic, but it doesn't bring direct value, which is why the focus is on product development, adding interesting features, and finding new use cases. Once decentralization is introduced, the product loses flexibility, and the ability to quickly modify, upgrade, and manage it decreases.
With centralization, it's different. There are various levels of centralization. For example, an exchange dictates the rules of the game. Then there's centralization where a centralized participant performs routine tasks—in our case, the relayer. It conducts basic checks, sends transactions but can't manipulate the content of these transactions. It can't take someone's money, change addresses or amounts, or double-spend.
Therefore, it's not crucial who launched and maintains the relayer. The only important factor is that it remains online consistently. The sole objective risk here is if the system suddenly shuts down one day and stops responding.
About the dev experience of building on Polygon and Optimism
We initially emerged on Polygon as that's how the cards were dealt. Currently, Polygon and Optimism are fully EVM-compatible, and there are no technical differences at the level of smart contract operation. However, when compared to something like Polygon zkEVM, there are technical nuances, despite it also being a fully EVM-compatible solution. There are subtleties, like the absence of certain precompiles or the like, which might affect the functionality of contracts in one network but not in another.
In terms of Proof-of-Stake and EVM, Polygon and Optimism are absolutely equivalent. This equivalence does not impact the development and testing of smart contracts in any way.
There are specific differences at the product deployment and operation levels due to the technical characteristics of transaction and block construction in both networks. Polygon has a known issue related to the unpredictability of reorgs, causing inconveniences at all levels, from the UI to the relayer and sequencer, and potentially leading to monitoring issues.
The situation is somewhat simpler in Optimism, primarily because it has a centralized sequencer, making reorgs impossible since there's no consensus mechanism that needs to converge—all is determined by a centralized participant.
About privacy pools and the working mechanisms of Tornado Cash
It’s evident that constructing privacy solutions without considering Tornado Cash is impossible. Tornado Cash has been the largest among previously existing privacy solutions. We understand the reasons why it can't be deemed successful, and it’s the same reason the entire industry consensus and all privacy-related matters inevitably encounter AML, KYC, and deposit amount limitations. Implementing these measures can prevent situations like those with Tornado Cash, where the protocol allowed for uncontrolled use for any purpose.
Mechanisms are needed that would keep the activities of this protocol within the bounds of decency and legal use cases. Technically speaking, both our protocol and Tornado Cash are built on zkSNARKS. However, delving deeper, the model used within the pool is somewhat different, though zk-SNARKS are utilized in both.
We plan to launch privacy pools for ETH or other volatile tokens because a privacy pool can undoubtedly exist not only for stablecoins. There are minor use cases with anonymous smart contract deployment, anonymous funding of new wallets, and the like. Therefore, a pool for native tokens will definitely be established as it presents its own unique appeal.
However, it should be noted that the zkBob pool originally emerged specifically for stablecoins and particularly for $BOB. Of course, a volatile token that can be bought/sold, incentivized, and dropped should appear. But this will happen in the future when we have a clear vision of the tokenomics built around the project, and when we can ensure profits for the token holders.
About investment funds and the market's interest in privacy
Currently, we don't require funding. The project is entirely self-funded, sponsored by the funds generated from previous projects and their successes. There isn't a critical need for investment rounds either, which is probably a good thing. However, it's understood that at some point, there will be a seed round for the finished project and for a future roadmap.
Everyone is interested in privacy. However, not everyone was ready to invest in it until a few months ago, primarily due to the unresolved situation with Tornado Cash. Although this situation is nearing resolution — the arrested individual has been released and granted internet access, which is undoubtedly positive news — the confidence that all investment funds will be interested in privacy investments is gradually building. Clearly, privacy is a significant niche with many use cases, demand, and substantial volumes for all transactions.
We observe that in the past, major protocols were responsible for the primary Total Value Locked (TVL) and Volume in privacy. These major protocols are no longer operational; using Tornado Cash has become unsafe, and both Aztec and zkMoney have announced their closures. However, these closures are not due to any internal issues; they are merely pivoting slightly towards a different direction related to ZK-Rollups, which they believe offers greater prospects.
Bootcamp: Solidity Developer
From the basics of Solidity to deployment on the mainnet.
Share
You might also like
Application submitted
We will get in touch with you soon
Interested in diving into crypto?
We're here to help!
or
Or connect directly