Lithos.eth

I really enjoyed diving into why privacy is so important, and hard to do right, with Laura. Thanks for having me on!

I’m glad to see @HeliusPrivacy bringing private payments and DeFi tools to Solana. A few folks have reached out to me asking about how Privacy Rings compares with Aztec. Aztec exposes a private smart contract environment through its language, Noir. Private state, private functions, multi-call contracts, account abstraction - developers write application rules in Noir and the Aztec framework handles the execution machinery. We aim to provide a complete abstraction layer that makes private smart contracts as straightforward to build as public ones. Helius takes a more focused, minimalistic approach. The core protocol defines a set of explicit SNARK circuits that encapsulate some functionality - like a private send, or a private swap. To assemble private transactions, devs take these circuits and combine them like lego bricks to build out more complicated transaction flows. This is actually similar to Aztec’s original incarnation in 2019. Our old toolkit had confidential notes and specialised proofs to do transfers, swaps and dividends, stitched together in a Solidity contract. We used these to demonstrate confidential lending in 2019. This was many years ago and back then the cost of one of our transactions on Ethereum would be orders of magnitude higher than a Helius transaction on Solana, but the core architecture is suprisingly similar. A disadvantage of the stock toolkit pattern is that if an application’s needs fall outside of the stock zk circuits (e.g. passport checks, compliance, validating web2 JWTs etc etc), what do you do? In Aztec’s case you just write what you need in a new smart contract. That’s what smart contracts are for. Helius does have a solution for this as well - their toolkit enables developers to write their own custom zk circuits that they can deploy to Solana. A noteworthy point about their architecture is that Helius uses Groth16 proofs, which require circuit-specific trusted setups. Asking developers to run their own setup if they need custom functionality pushes a substantial security requirement onto them. Particularly in the age of AI where an increasing avalanche of CVEs means it’s harder to know the code you’re running is the code you *think* you’re running - multiparty trusted setup processes are more vulnerable to attacks that leak participant toxic waste. Either you keep the setup ceremony secret, which undermines trust you did it correctly, or you’re open about it and you broadcast to attackers exactly what they should be targeting. The trusted setup problem weakens composability because a developer integrating a 3rd party zk circuit needs to have confidence the 3rd party ran their setup correctly. This issue compounds as more 3rd party trusted setups are added into the ecosystem. I’m curious to see how the Helius team works to ensure every trusted setup ceremony for every custom zk circuit deployed is trustworthy. The trusted setup problem was why I went down the road of co-inventing Plonk - I wanted Aztec to support private composability without requiring app developers to run trusted setups whenever they needed a new circuit. Compliance and shutting out bad actors is a shared challenge and I am interested in seeing how Helius will approach it. Their initial deployment of Privacy Rings does not hide the transaction graph, and only hides transfer values. This is a weak form of privacy, but it looks like they will add more advanced rings soon that do hide the transaction graph. At that point you either need to permission people in/out of the system, introduce an auditor backdoor key, adopt privacy pools style proofs of innocence, or try something more novel. I am curious to see how Helius and the Solana community wrestle this bear of a problem and what solutions end up becoming canonical on their network. One thing that really stood out to me was that they have an explicit circuit for what in Aztec we call “constrained note delivery” and what Helius calls “take_verifiable_encryption”. When doing a private send, having a way to verifiably prove that the recipient is able to decrypt and read the private data is essential for private composability. Helius is the only privacy project outside of Aztec I am aware of that realises the need for this functionality (and I would say that private composability is pretty damn important). From this alone I can tell this team is no joke and they know what they are doing. To try and summarise all of this: Helius is a compelling and legitimate attempt to go beyond private transfers and build composable private DeFi primitives. It makes very different tradeoffs to Aztec. For basic transaction profiles (and most crypto transactions are basic), their system works well and is less complex than a protocol like Aztec, and that complexity comes with its own tradeoffs. For more complex needs, edge cases and novel designs not covered by the stock Groth16 circuits, Helius pushes more complexity onto the developer and requires them to successfully execute trusted setups, which adds what I would consider to be a substantial security risk, although that is my subjective opinion. It’s also interesting to see how the tradeoff space changes because of Solana’s execution environment. On Ethereum, mainlining a chain of Groth16 proofs into an atomic transaction would be unworkable due to Ethereum’s compute limitations (the gas cost would be astronomical). On Solana, this is not a constraint and this allows for rapid throughput from Helius’ architecture. This is clearly a metric they designed for and their minimalistic abstraction layers allow for a very impressive transaction throughput. I’d love to explore shared work with Helius and Solana builders on the many common problems we will experience making crypto private by default. There's a lot we could learn from building solutions together.