I said it was hard, not (necessarily) impossible. 
I’m not sure if I would call that approach trivial compared to Eth1’s account based one, but I haven’t played with it so you could be right.
Is there a more detailed write-up of this approach? I’d like to learn how a Uniswap equivalent would work, especially with multiple concurrent users. Or the sort of funny composition transactions people do in DeFi arbs.
With covenants you can define a spending condition on an UTXO. How would that work for a pool?
The UTXO is anyone-can-spend, under the condition that the transaction that spends it produces an output that transitions the UTXO’s state based on some data in the transaction (an implementation detail). Now replace “UTXO” with “contract account” and you see that it’s trivial to define open contracts in the UTXO data model. Just make UTXOs able to hold state and contract code! Which is exactly how contracts on Ethereum differ from EOAs.
This should come as no surprise because UTXOs are almost exactly the same as accounts with mandatory strict access lists (there are some minor differences, but they’re outside the scope of your question).
Can two people deposit into the same UTXO and a third spend it without the first two revealing to the third how much they deposited ?
I don’t see how that would be possible without leaking any information. You could probably make sending funds to the contract private, but you’d always need everyone (since it’s anyone-can-spend) to know the current balance. At best you’d be able to obfuscate the source of the funds, not the amount. Kind of like Tornado Cash.
ZkVM enables two party shared UTXO to be committed in a contractID to be spent according to the constraint, without revealing to the third party the amount in the commitment.
Who makes the spend proof ?
if the constraints are public, then the taker would generate the proof.
So in the example above you said two party shared UTXO. This is a maker taker atomic swap?
Assuming so then party 1 the maker shares the balance of the UTXO with party 2 the taker who then creates a ZKP to consume that UTXO. In this case the maker needs to share their private information with the taker in order to have the atomic swap processed.
Now if you expand this from 1 party the taker being able to execute. To many parties being able to execute them you the taker needs to share their private information with everyone. Thus you lose privacy when you gain the ability for anyone to execute.
Hey @barryWhiteHat if a user triggers the execution of uniswap’s contract from outside of the chain he/she remains incognito, while the contract executed publicly. I’ve published this work recently pEthereum - privacy mode for smart contracts & integration with DeFi.
What do you think about such implementation? I am quite open to critique, feel free 
So basically you have a private erc20 tokens. Where you don’t know who owns which tokens and then you trade these tokens on uniswap or compond ?
So the ownership of the tokens is private but what you do with them trade on uniswap or compound is completely public. This post is claiming that you cannot make a uniswap which is not public. So your approach does not discount that.
What do you think about such implementation? I am quite open to critique, feel free
I left some comments on the other post as I feel its a more natural place to discuss.
This isn’t quite true; you have to choose what kind of information you reveal. For example in ZEXE we show how to construct private DEXs that offer varying levels of privacy for the maker and the taker. In one construction, the only thing onlookers learn is that a party was interested in performing a trade for A to B (not even amounts are revealed)
I’m working on a similar project where we take a different approach. One thing that was noted by my collaborators is that your reasoning on seems to hold if you use non-malleable ZKPs. Thus, malleable ZKPs could possibly help get around the lack of a shared global state.
Hey, is there any paper about malleable ZKPs, it’s really cool
Is it possible to do account-based privacy using something like erasure encoding? For example, rather than having one storage slot correspond to one person’s balance, have maybe four storage slots corresponding to four people’s balances. Idk if erasure coding is the way to do this, but the idea being several people share the same storage slots. So when they are accessed/written, you can only identify that it is one of those four people. I’m not an expert. Is this possible or make sense?
Oh cool so the person who produced that proof would have to have the private info. For example all the data about the uniswap pool. Its an interesting idea but i think that a fully functional version of this would be obfuscation. Which I think is still pretty hard.
The problem with private account model. Is that I can send x amount of coins to your account. Then refuse to tell you how x is and then you are unable to make a proof of your balance because you don’t know what it is. There are some approaches to solve this but they kind of degrade to input output. So i am not so excited about account model in private systems.
Is it possible to do account-based privacy using something like erasure encoding? For example, rather than having one storage slot correspond to one person’s balance, have maybe four storage slots corresponding to four people’s balances. Idk if erasure coding is the way to do this, but the idea being several people share the same storage slots. So when they are accessed/written, you can only identify that it is one of those four people. I’m not an expert. Is this possible or make sense?
This does makes but I think this 1 of 4 would reduce your anonimity alot. Also you have to ensure that you know the amount of every inbound transaction in order to avoid the problem descibed above.
Thanks for writing this; we ended up writing a bit to formalize this as an attack for generic constant function market makers. The idea is basically to take advantage of the convexity of the invariant functions used and use that to iteratively approximate what the true trade size executed was. The convexity of these invariants (e.g. constant product, constant geometric mean, convex sum of the two) effectively makes it possible to infer the true and unique (this is the main theorem) trade size involved.
The doc link needs permission to access, it it possible to share it public? Thanks!
Probably has been superseded by this paper of theirs: [2103.01193] A Note on Privacy in Constant Function Market Makers
And there is an ethresearch post by tchitra on this topic: Differentially Private Uniswap in ETH2 - #4 by tchitra