[RFC] Solidity snapps doc

[mrmr1993]

No description provided.

[imeckler]

In the implementation, the snapp public input currently consists of

• the full party stack (hash)
• the party stack at the point of the current party (hash)

[imeckler]

This should not trouble us much as a push/pop is just one hash, which is pretty cheap (and will be even cheaper in the new proof system)

[imeckler]

This is as easy as changing the "transaction commitment" used for the public input to include the fee_payer.

I will note that there is a bit of a trade-off here, as we'd lose the ability to have transactions that were proved independently and then sent off by someone. We could do both by including a bit for each party that says whether it wants to be verified against the public input that includes the fee-payer or the one that doesn't... but that adds some complexity

[mrmr1993]

Does it make sense to have it as a predicate then? This means its still accessible by querying the party if you want it, but otherwise gives separability.

Should we consider doing the equivalent for parties and the stack below the current party, so that a snapp can always be proved in isolation if it doesn't depend on these?

[imeckler]

Amazing, left a few comments

[mrmr1993]

Option for on-chain delayed roll-up: accumulate the pending updates for the current block, and hold onto the updates for the previous 5 blocks (15 minutes to do the roll-up). Then, a roll-up can trigger on any of those updates.
This would be something like

type state =
  { last_updated_slot: Slot.t
  ; pending_updates: Update.t Stack.t
  ; prev_updates1: Update.t Stack.t Stack.t
  ; prev_updates2: Update.t Stack.t Stack.t
  ; prev_updates3: Update.t Stack.t Stack.t
  ; prev_updates4: Update.t Stack.t Stack.t
  ; prev_updates5: Update.t Stack.t Stack.t }

where prev_updates_n = Stack.push prev_updates_{n+1} updates_for_some_block

I think this is pretty cheap in the circuit:

let push_update update state now =
  let is_empty = Update.is_empty update in
  let state =
    let update = not (is_empty || Slot.equal state.last_updated_slot now) in
    let
      { last_updated_slot
      ; pending_updates
      ; prev_updates1
      ; prev_updates2
      ; prev_updates3
      ; prev_updates4
      ; prev_updates5 } = state in
    let new_prev_updates = Stack.push prev_updates1 pending_updates in
    { last_updated_slot= if update then now else last_updated_slot
    ; pending_updates= if update then Stack.empty else pending_updates
    ; prev_updates1= if update then new_prev_updates else prev_updates1
    ; prev_updates2= if update then prev_updates1 else prev_updates2
    ; prev_updates3= if update then prev_updates2 else prev_updates3
    ; prev_updates4= if update then prev_updates3 else prev_updates4
    ; prev_updates5= if update then prev_updates4 else prev_updates5 }
  in
  let new_pending_updates = Stack.push state.pending_updates update in
  {state with pending_updates= if is_empty then state.pending_updates else new_pending_updates}

let check_update_predicate update_predicate state =
  List.any
    [ Stack.equal update_pedicate state.prev_updates1
    ; Stack.equal update_pedicate state.prev_updates2
    ; Stack.equal update_pedicate state.prev_updates3
    ; Stack.equal update_pedicate state.prev_updates4
    ; Stack.equal update_pedicate state.prev_updates5 ]

This comes out as

• 2 hashes
• 6 equality checks
• 7 if statements
• snapp account size increases by 6 field elements + 1 slot = 6*32 + 1*8 = 200 bytes

Note that rolling-up after a delay complicates cross-snapp calls, since updates involving roll-ups are no longer atomic.

[mrmr1993]

!ci-build-me