Verifier doesn't calculate ℎ1(x), ℎ2(x), ℎ3(x), prover has to. Therefore, simply sending a F(x) is not enough, prover still has to send ℎ1(x), ℎ2(x), ℎ3(x).
The optimization in the paper works as follows:
With ℎ1 evaluated as c, a constant, verifier can computes () themselves, which utilizes the (additive) homomorphic nature of KZG commitment scheme.
prover then calculate (x) and proof π to prove (x) = 0.
Here's the sketch of how homomorphism of KZG commitment scheme:
\begin{align*}
& \text{Com}(h_1) + \text{Com}(h_2)\\
&= G \cdot h_1(\tau) + G \cdot h_2(\tau) \\
&= G \cdot (h_{1,0} + h_{1,1}\tau + h_{1,2}\tau^2 + \ldots + h_{1,d}\tau^d)
+ G \cdot (h_{2,0} + h_{2,1}\tau + h_{2,2}\tau^2 + \ldots + h_{2,d}\tau^d) \\
&= G \cdot [(h_{1,0}+h_{2,0})\tau + \ldots + (h_{1,d}+h_{2,d})\tau^d]
\end{align*}
How would the verifier verify that ℎ1()= is actually true without having a commitment to ℎ1 also which is opened at
? After the verifier sends a random value to the prover, the prover can calculate ℎ2() & ℎ3() & calculate a such that ⋅ℎ2()−ℎ3()=0?
Prover outputs commitments, $([a]_1, [b]_2, [c]_1)$ in round 1, that's why this opening can be verified. The commitment of round 4 opening evaluation have all been submitted in previous round or as common preprocessed input.
ref:
https://cacr.uwaterloo.ca/techreports/2010/cacr2010-10.pdf