Agnostic code cannot be native of course, but…
Among elliptic curve based protocols there are only a handful of really slow procedures: scalar multiplications including subgroup checks, multi- scalar multiplications, G2 point preparation, multi- miller loops, final exponentiations, scalar multiplications etc in G_T, and FFTs for scalars and points. We’ve started adding host calls for selected procedures from this list in substrate PR 13031 linked above.
As a rule, cryptographic protocols invoke these only O(1) times during verification, although some like MIPP needs O(log n) which makes marlin O(log circuit_size) and snarkpack O(log batch_size), and some like bullet proofs need linear O(circuit_size) time, but then batching maybe improves things, sometimes dramatically ala halo2.
Importantly, there is enough variation in batching optimizations that again you cannot simply make a few native verifiers fit everyone. We do however want higher bandwidth between on-initialize, individual transactions, and on-finalize, because batching requires moving part of transactions verification into on-initialize and/or on-finalize.
Among protocols like STARKs not based upon elliptic curves, we’ll explore doing acceleration eventually, but…
There is much more variability so exactly how we what acceleration remains uncertain. It’s uncertain which protocols even dominate here too. At present STARKs have kinda poor security margins, but they’re likely fairly safe otherwise, and the otherwise maybe matters more than the security margins.
At least some lattice folk argue that lattice based zk proofs soon out perform STARKs across many applications, so maybe STARKs loose out in a few years, or maybe not really. At the same time, lattice are an quagmire of foot guns, aka job security for cryptographers, so lattices might fit poorly with the blockchain worlds’ current rushed & slipshod development practices. Expect chaos.