When using the ᴇɪᴘ‑197 precompile, is there a risk of forgery when allowing the degeneracy of bilinear pairings when using Groth16 with public inputs ? If not, how to rework the Groth16 protocol in order to let verifier ditching a pairing e(C,vk) when calling the precompile as a gas saving measure ?

The non degeneracy criteria is there’s no bilinear pairing resulting in the finite field element 1 equivalent.

In the case of the optimal ate pairing, this can happen if one of the point of the pairing is the point at infinity : then whatever is the other point in the key, the result will always be 1.
For that reason, Zcash prevent the prover from fully controlling proof inputs and thus provide no encodings for the point at infinity.

On Ethereum, the prover often can set without filters A ; B ; C. And the only check in ᴇɪᴘ‑197 is points must be on curves and implementations just skip the compultation of bilinear parings containing a point at infinity : as long as the end result is 1 in $F_q¹²$, the contract call can succeed even with 1 or 3 points at infinity $(0,0)$

But what would happen if it would be the cases as it’s happening on some implementation that use the Ethereum’s ᴇɪᴘ‐197 precompile ? There are clear examples on how to forge proofs when there’s no public inputs or they are allowed to be all 0 but are there security risk when public inputs are used and if yes how this can be done ?