How feasible is the entire payment then? How long will it take for sender to upload and for receiver to download and verify 17 GB of data and then pay the change back and then for the sender to verify the proof for the change? Uploading 17 GB of data will mean days for many people that have asymmetric DSL.
Most of the coin validity proofs are exclusion proofs, and those can be compressed using SNARKs/STARKs. For e.g. if we use constant-sized proofs this means that a coin validity proof will only increase in size when a coin is spent.
We know that withdrawing and re-depositing a coin will “reset” the length of the coin validitiy proof; this construction allows you to do this at an amortized cost of 1 bit of storage (SSTORE) per coin.
We can combine these two techniques by doing a checkpoint when even the compressed proofs get too big. Analysis: with checkpoints, we can have the coin validity proof grow as$ O(f(n))and the per-unit-time cost of owning a coin grow as$ O(g(n))with the constraint that$ fg \in O(n)where$ nis the total number of plasma blocks (i.e. increases by 1 per minute).
For succint/scalable verification technology in general, this depends on the exact construction and there are trade-offs, eg STARKs have lower prover cost and longer proof sizes (hundreds of kilobytes vs hundreds of bytes). The trade-offs come into play because depending on exactly how you want to compress the proofs, maybe the verification must be doable on-chain, or maybe it is sufficient to do them client-side.
For the specific zk-SNARK construction I believe that the verification costs is low (dominated by two elliptic curve pairings) but the costs of the trusted setup as well as prover cost are quite high (@kfichter estimated hours per plasma block to produce a proof of the validity of an entire block). For asymptotic costs I have the following table in my notes (note: I don’t understand everything in this table!) for the cost of doing various things for an arithmetic circuit of with$ Nwires,$ lof which are public: