ZK Rollups:

• Needs ZK verification and recursive covenants.
• Examples:
  • OP_CAT (verifier needs 2–3 MB).
  • GSR (includes CAT + other opcodes to make verifier more efficient).
  • Even a 32bit MULT would be bigger than one tx
• Recursive covenant required to carry state of rollup from one transition to the next and move the coins from one state to the next.
• Is there a minimal set of TX introspection opcodes to get the recursive?
  • Big inputs to SNARK can be parsed inside the SNARK
• Alpen labs uses liquid introspection opcodes - there are many. Introspection implies recursive covenants, CTV is too weak, and can not reason about inputs which is necessary.

Shielded CSV (Client-Side Verification):

• Needs a bridge.
• Needs chain introspection to detect nullifiers in the chain (e.g., OP_BLOCKHASH).
• Without introspection:
  • It makes assumptions about the attackers hash rate.
  • Alternatives: Nullifiers consumed by UTXO or sent to bridge "contract"/accumulator.
• Non-optimistic protocol needs OP_CAT + OP_MUL (or GSR) to verify SNARK on chain.

ZCash-Style Protocol on Bitcoin:

• Needs new address type.
• Needs new tx field? Could fit in OP_RETURN.
• Might need something like an extension block.

Sidechains:

• Needs light client for the sidechain in bitcoin.
• Has its own consensus mechanism.
• Also needs recursive covenant.

Zero Knowledge Contingent Payments:

• Requires knowledge of the solution when setting up the contract. So order of things is the backwards.
• Does not require recursive covenants.