Roll Up Meeting 2 Agenda

[barryWhiteHat]

Meeting Time/Date: Thursday 27 Sept 2018 at 12:00 UTC

https://meet.jit.si/SlyMushroomsCommunicateFlatly

1. Introductions
2. Could collaboratively write a high level summary of exit/rollback so its easy to digest. https://hackmd.io/Vf0UGeuvR2mgApVS60VepQ?both
3. Questions about yellow paper https://github.com/barryWhiteHat/roll_up_yellow_paper
4. Other?

[HarryR]

Merkle tree, tracks balances snark updates merkle tree, ensures transation to only legal states exits simpler, because can never create invalid states - prove they can go from old state to new state before you can withdraw instead we elect somebody called an operator, who creates these snark updates on the chain and publishes them person is very constrained, can censor transactions, or create a state and not share, but cannot steal anybodies money without the spend signature

big problem is data availability - prevents people from using system

priority queue = request to exit any user can enter queue operator must process the queue if they dont service within a given time limit they get slashed when operator gets slashed, we assume data is unavailable then begin roll-up

two step process

1. open auction - want to become a new operator, say which block they want to start from
   • most money at most recent state = new operator
2. then roll back to that state, block by block at each block, give users a chance to exit 'i dont want to roll back, i have money in this, let me exit now'

users dont have to watch the chain 24/7, they dont always have to be watching to prevent people from stealing their money

pushes responsibility onto operator, if they dont act quickly enough and will get slashed

• in proposal, users can only update ownership of a leaf, cannot update the balance
• all leafs have a fixed value
• can use a state channel, similar to plasma debit
• updating balances makes everything difficult, different balances at different points of time = double spend on two different leaves, take more out than they put in etc.

[HarryR]

priority queue - everybody has to use the priority queue to exit, or else you can force the operator to give some data that you don't own - e.g. forcing data availability.

fast exit - using the Ethereum address key in the LHS of the leaf next to the public key, will add an extra hash function to the constraints. There is an edge case, if a user performs a fast exit then the operator updates the block - the nullifier will be on-chain, but the owner of the leaf in the merkle tree will be different. This scheme breaks the 'insurance scheme'?

put delay on priority queue, but have delay on fast exit.