[pre-MIP] Make `access` permission affect tokens only

[L-as]

It's desirable to allow other zkapps to read your state without needing a proof (which on L1 might not even be feasible because of account update limits), but setting access = None also means your zkapp can't be a token owner practically, since all token logic would be completely unchecked.

A simple way of doing this would be to check access permission only if account update has children.

It's not clear to me what the original motivation for the access permission was beyond token owner control.

[mrmr1993]

It's not clear to me what the original motivation for the access permission was beyond token owner control.

The original design also had a way to interrogate the parents in the zkApp call tree, but this was cut from scope. It's useful to introduce this later -- and I believe that you agree -- but then the only way to ensure that your desired parent really is 'calling' into your zkApp is also using the access permission.

I think we should be careful with the intended final semantics, and thus disagree with / oppose this MIP.

[L-as]

The original design also had a way to interrogate the parents in the zkApp call tree, but this was cut from scope. It's useful to introduce this later -- and I believe that you agree -- but then the only way to ensure that your desired parent really is 'calling' into your zkApp is also using the access permission.

It’s not clear to me why you’d want to constrain this? You would only be able to “call” the zkapp if the proof verifies for the caller anyway, or no proof at all, in which case I don’t see the harm.

But in any case, I assume that you would agree that it would be beneficial to split it up into two permissions?

[mrmr1993]

It’s not clear to me why you’d want to constrain this?

A good example is authorising token withdrawals from a zkApp. For example, ideally you want a structure like

{ "identity": "zkApp"
, "token": "MINA"
, "children":
  [ { "identity": "token zkApp",
    , "token": "MINA"
    , "children":
      [ { "identity": "zkApp's token account"
        , "token": "token zkApp's token"
        , "balanceChange": -5
        }
      , { "identity": "user's token account"
        , "token": "token zkApp's token"
        , "balanceChange": 5
        }
      ]
    }
  ]
}

Where the zkApp's token account needs some guarantee that the withdrawal is permitted. If we introduce the ability to look up the call-stack, that account can check that zkApp authorised the withdrawal, but this only works if access: None. Otherwise, a withdrawal could be triggered by 'accessing' zkApp to just read its state (or even as a no-op), and its tokens could be stolen.

I assume that you would agree that it would be beneficial to split it up into two permissions?

I'm not sure do I agree here. To your original question though,

It's desirable to allow other zkapps to read your state without needing a proof

it's interesting to consider a read-only mode for account updates that doesn't require the owner's contract to be involved. This adds a small design constraint to the 'call stack introspection' I mentioned, but I think it's sufficient to require that such read-only account updates are excluded from the introspectable call stack.

To be concrete: as long as we constrain that an account update has no effect (outside of preconditions) then we can ignore access safely IMO.

[L-as]

MinaFoundation/mina-fungible-token#112
very relevant