# Zkbob and Kalypso

## New ZkBob setup
We are currently undergoing a significant upgrade where the sequencer role can be filled by an untrusted party.
1. User generates a proof that the transaction is valid ( the source note corresponds to a existing root and nullifier and tx commitment are correctly generated)
2. User sends tx commitment and nullifier to a 3-rd party that would post it onchain on user's behalf to avoid gas payment
3. Proxy checks for existing duplicates in the Queue, checks transaction proof and nullifier absense in the contract (double spend)
**Important note 1:** this is a statefull check that requires access to Pool contract and Queue contract.
**Important note 2**: if the check is successfull then the transaction will be eventually settled if liveness assumption holds
4. Proxy publishes tx commitment to the Queue contract
5. Prover fetches latest transactions and generates a new root alongside with a proof and publishes it onchain. This results in fee transfer from the Pool contract to the Proxy and Prover
## Naive setup with Kalypso
Our goal here is to offload prove generation to a trusted process inside enclave. The main challenge is to charge Alice only when the transaction is settled and to prevent identity leak
We can try to replace local prover with Kalypso marketplace but there seem to be few problems
1. The data that is needed to create proof is sensitive (eg user account balance) and cannot be disclosed to an untrusted party such as [smart contract](https://github.com/marlinprotocol/Kalypso-SDK/blob/master/test/proofRequestor/99_submitAsk_TransferVerifier.ts)
2. There is no guarantee that Alice sends resulting proof further so tx can be left abandoned and prover's cost would not be reimbursed
3. In order to interact with a contract Alice needs to spend gas which could compromise her identity

## More secure setup
In order to handle Problem 1 we have an option to encrypt the data which is mentioned in Kalypso example. The important question here is how does Alice determine the particular Prover and their respective public key?

In order to handle Problem 2 we propose to merge roles of generating a transaction proof and posting it to the transactino queue. That would prevent DOS and draining attacks but that would require enclave to be able to call Pool contract and Queue contract (*is that possible?*).
This solution seems to be especially fruitful because it also solves the lack of available proxies to interact with which is very important to ZkBob protocol and others alike.

Solving Problem 3 seems to be quite hard. Few available options:
1. (Temporary, unsustainable) Deploy an additional proxy to interact with the contract, subsidize gas. Spam protection can be done with [RLN](https://rate-limiting-nullifier.github.io/rln-docs/rln.html)
2. (Need more research) Force Alice to buy prepaid blinded tickets (using Chaumian blinding scheme, [more sophisticated option](https://www.petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf))