-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow cancelling deposits #176
Comments
Perhaps rather than merely recording L1 action state on the L2, we could transport something more meaningful over. |
Solution without deletion and new accountsHow can we support cancellible deposits? This turns out to be a considerably complex problem in the Mina setting, After much thought: Take the current design, and associate with each deposit a max slot, before If there is no sequencer (e.g. they get nuked), the user should be able to cancel their deposit We can do this by extending the types of actions we support as such: type action =
| Deposit of { amount : nat, timeout : slot }
| Uncommitted of { min_slot : slot }
| Committed of { max_slot : slot } Whenever the sequencer commits, they must make a Conversely, any user can at any time submit an Thus, We now have another issue: The sequencer chooses some Or perhaps it does but a rollback happens. We might miss our window of opportunity and the transaction will be invalid, Well, we already have a solution for this! Already we don't need to transfer the latest action So we change our design a bit: type action =
| Deposit of { amount : nat, timeout : slot }
| Uncommitted of { min_slot : slot }
| Committed of { action_state : action_state, max_slot : slot } When we commit, we update the inner account's record of the outer account's action state On the inner side then, to prove that your deposit has been accepted, you must show that it happened To show on the outer side (L1) that it's been rejected, you must show that Then we must treat a cancelled deposit similar to a withdrawal, that is, We use the exact same mechanism as for withdrawals. We also need to consider incentives however. Why would the sequencer choose a low So we can instead force the sequencer to choose a low There is one more issue: But in any case, it's an exceedingly minor vulnerability since you need to spend L1 fees One last point: Rationale (failed alternatives)How can we do cancellible deposits? But this won't work because:
The first reason is a deal-breaker. But why then do we need the new actions?
In essence, we're creating an indeterministic ledger in the action state, |
This is not really feasible with the current architecture.
If we had deletable accounts (UTXOs), it would be trivial, since you could create an account per transfer,
but since we don't, it's heavily complicated.
If we in addition to recording the deposit in the action state record it in a dedicated account, and allow marking the transfer as cancelled there, we could do it, but it would be a somewhat big change to how it works.
We already have a dedicated account per user for transfers though to ensure there is no "double spending" of transfers,
and we could possibly use this again.
But we also have to consider that failed transactions still take fees, so if we do cancelling naively,
i.e. by matching against user account with some precondition that fails if user cancels it,
then user could cause sequencer to waste fees.
This is bad obviously.
You could also just make it a timeout. This would probably work better.
If more than X time has passed where the transfer hasn't been processed,
that probably means the elected sequencer has not been processing transfers on purpose.
If there were no sequencer, it would be trivial to pay a small fee and become sequencer and process your own deposit.
So let's consider it again, if more than X time passes since you've posted your action (enforced by including min slot precondition in action), and it hasn't been processed yet (which we know since we track how much of the action state we've processed),
we allow cancelling it.
But how do we prevent it being processed after cancellation?
We make cancellation automatic, it expires after X time.
So let's say user hasn't withdrawn the funds from the cancelled deposit yet,
but the sequencer has moved the action state past it.
How can the user prove that the processed action state moved past it at a pointer
at which it was already expired?
We could emit events that show when the action state was processed,
or otherwise record it.
You'd also have to show that a deposit wasn't expired when processed on the other side
to prove you can take the funds.
This is quite complicated.
If we however have deletable accounts, it's all much simpler.
We create an account per deposit in unison with the outer account,
as a token account, record the information for the deposit, along with when it was created.
When we process the deposit, we destroy the account.
After a certain point in time, it no longer becomes processible,
and anyone can cancel it and send the funds back.
But we'd also have to change how we transport the information to the L2.
On the L2 we'd have to record a digest of accounts processed on the L1.
This would also be quite a big change.
The text was updated successfully, but these errors were encountered: