Ah, thanks for clarifying, I think I’m following what you’re saying. To reiterate in my own words, so you can correct any misunderstandings:
SNARK exclusion proofs
Basically Plasma Cash, but a coin’s history’s validity is ensured by a zkproof over blocks proving that no txn of that coin occurred. This makes the history a lot faster to validate, since all the blocks between txns collapse into the single zkproof of exclusion across all of those blocks.
I like this idea for the near-term, I agree that it’s much closer to reality than a proof over the entire state transition. Although I’m unsure that this design is “viable enough” to be used out in the wild by tons of people-- do you think this would be enough? Maybe with some kind of checkpointing-- otherwise there may be too much data to transfer from sender to receiver for each txn.
Once we have these proofs, I’m pretty sure we won’t need the exclusion proofs anymore; a txn’s inclusion along with its validity proof imply its valid history. It seems like we’re on the same page on this. I haven’t dug into how predicates could fit in to this kind of system, but my guess is we could have a transfer of a token be validated by a proof over an arbitrary predicate nearly as easily as just by a signed message from current owner.
Admittedly I haven’t actually gotten my hands dirty with the zkproof implementations yet, and it’s easy for me to say “just snark the whole state lol” vs actually implementing and running it in reasonable time. My gut feeling is that some kind of batching or aggregating of proofs will be a leap forward in enabling magic stuff like this, and without any kind of batching it may be difficult-to-impossible.
Thanks for the conversations Karl! Excited to see the progress of this work inching towards production