You should verify the proof multiple times, but there's no reason to generate it multiple times. If there was an error in the witness generation proper verification will catch it, and if there's a problem with the verification regenerating the witness will not help.

..and then rewrite it again via a clean room approach and run that one and see if they tally.

Preferably on different hardware.

The Pi (and other mathematical constant) computation records don't go that far. They verify random results towards the end with a different algorithm.

Excellent point.

Hardware error is almost certain in this case. c.f. rowhammer or bitsquatting.

I think it would be pretty unlikely to trigger rowhammer accidentally. The incidence of random (memory) errors is very low. Something like once every 1.5 years...

This study from Google is pretty interesting:

http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf

I compared to rowhammer and bitsquatting.

From the paper that you cited:

Our first observation is that memory errors are not rare events. About a third of all machines in the fleet experience at least one memory error per year (see column CE Incid. %) and the average number of correctable errors per year is over 22,000. These numbers vary across platforms, with some platforms (e.g. Platform A and B) seeing nearly 50% of their machines affected by correctable errors, while in others only 12–27% are affected. The median number of errors per year for those machines that experience at least one error ranges from 25 to 611.

You have hecksums and other internal consistency checks to deal with those.

They won't actually help. With hecksums, you're darned if you do, and darned if you don't.

;-)