The problem of using complex scripts, like OP_LOTTERY, to introduce that kind of system in the first place.

For example, you have a famous HI-LO game (but not only that). Your deposit is your transaction fee, so everyone is playing, except for example miners, doing transactions in a range of 0-1 sat/vB.

An example of getting numbers in range 0-10000, to determine the result of some round: https://s3.amazonaws.com/roll-verifier/verify.html

If you would want to get it on-chain, you would need something, like an additional OP_LOTTERY opcode, which would return you a single number in range 0-10000, and then you would have some "OP_IF <winnerKey> OP_ELSE <minerKey> OP_ENDIF OP_CHECKSIG", to claim the reward.

For this purpose, all that is needed, is having a blockchain (which every full node has). Also, pruned nodes keep the last N blocks, so it should be sufficient for verification of the latest lottery rounds.

In general, verification is easy: you observe the chain, and you know, how many nodes are running the lottery, and how many are not supporting it. Then, you can make some statistics, and determine, how many coins should be sent to the users, to keep the lottery running. And as long as there are enough miners, willing to share their fees with the community, the lottery can run indefinitely, and encourage new users to participate in next rounds.