This is absolutely detectable on all central limit order books including centralized/fiat exchanges of today. It may not be provable in many instances. The victim and anyone else who can see the victim order will basically see the price move through the victim order and fill a different order at a worse price. i.e. If you had a limit buy at 200, the price will fill 199 before filling your order.
Orders are timestamped by the user AND the operator. The users order timestamp serves to ensure the operator is time-stamping accurately. The operators timestamp serves as the single clock of reference for a price time priority proof. A small clock skew is tolerated to ensure variable ping delays.
As a practical matter, the user clock is adjusted from the server price feed and the skew is adjusted automatically, so for all practical purposes the requests will have nearly same timestamp as the server.
Note that front-running requires the deployment of capital and the smaller the price movement, the larger the capital allocation that is needed to make the same amount of profit. Large ticks on futures products ensures that even if the underlying spot market moves a bit (due to 6 decimal places) the futures product is unlikely to move (due to 1 decimal place) within a span of a few milliseconds. While there is a theoretical possibility of operator frontrunning in the skew tolerance (difference between user and server clock), the profit collected would be so small that its not economically attractive to deploy a huge amount of capital for it; it would be more attractive to just lend it at interest.
When data is unavailable in Gluon Plasma, it affects all users since the rootHashes wont match and they won’t be able to exit. Also note that if the operator steals from one person, everyone else should know they are next and the only rational course is to halt the chain.
Do honest large stake owners have to lose 10% of their tokens every time they vote
If the operator is compromised, there is a very good chance that the governance tokens are nearly worthless in a few hours. Its better to sacrifice 10% of them and save other assets. On the flip side a malicious person would be discouraged from voting falsely or carelessly since they would have to pay with valuable tokens.
an adversary’s prior vote has a long-term accumulative impact
Everything is reset when a new G-block is created.
but this does increases the finality time
Perhaps there is a chance that someone will spend $100K maliciously to delay a G-block by 10 minutes. Or $2M to delay by a few hours or $200M to delay by a day. Its certainly possible since there are some wealthy folks in crypto who have “more money than Rwanda”, but I think its highly unlikely they will dump so much money on a temporary prank, whose only lasting effect is to advertise the robustness of the thing they are attacking.