Just set it up to boot into a RAM Drive. Then nothing ever writes to the device (except for settings modifications which should only happen once in a blue moon).
Yep. That's what I do with network boots. Any modifications occur upstream, when I regenerate the network image; no need to write, ever [except to local ramfs].
Some kind of netboot is a fine solution, but then one would need to maintain TFTP server and other stuff as well as some kind of shared fs. Again it's a single point of failure, possibly needs to be duplicated, Nothing impossible, but it all has it's own set of things to take care of.
That is so 1990s
A better firmware means you can HTTP after DHCP, so my network boots occur from redundant HTTP servers into RAM. No shared filesystem, no single point of failure besides the network and power cables. Those management firmwares and processors in modern server systems are pretty darned fancy these days.
Even with an older firmware, all you would need is DHCP/PXE/TFTP to download a kernel, and an initramfs packed with everything a miner needs. Or the initramfs could be the first stage of userspace download into RAM.
As an aside, though you must still boot a gPXE image, rather than straight HTTP like I've set up locally, here is a fun project: http://boot.kernel.org/ Booting an OS over HTTP.