Usually an "evil" delegate won't submit orders by their own account, instead, they may submit the front running orders from a couple of other accounts. This may make the statistical analysis more difficult.
By the way, if you encrypt an order for a special delegate, what will happen if the delegate missed its block, even if be voted out of top 101?
Okay, after thinking it through more, I am reconsidering the statistical analysis thing.
Here is how I originally saw it working. At any given time the client would determine who the next two delegates in the round to sign blocks are. If there is only one delegate left before the round ends (which should happen only 1% of the time), the client would simply delay for 10 to 20 seconds until the new round order is determined and the first two delegates of that new round are selected. The signed transaction is encrypted with a one-time symmetric key which is then encrypted twice (one for each delegate) and attached to the encrypted signed transaction and broadcast on the network. Furthermore, the expiration time of the transaction would be 30 seconds in the future, so if it doesn't get into the blocks produced by either of those two delegates, that particular transaction won't be added to the blockchain at all. If both delegates miss the block, the client (realizing this 30 seconds after the transaction was broadcast) will create a new transaction and try again. Most likely, it will get the transaction into the block on the first try.
Only encrypting the transaction for two delegates is important. Those who can decrypt the transaction are able to get access to the information that could allow them, or anyone they wish to help, to front run the market/limit order specified in the transaction with a high probability of success/profit. So it doesn't matter which account actually does the front running. We can simply assume that if there are three transactions in a block in which two of them conveniently were able to buy low and sell high to the third transaction, it is a mark of suspicion for either the delegate producing that block or the delegates producing the blocks immediately preceding it or immediately succeeding it. These bad marks can be accumulated over many rounds. Because the delegate order is randomized every round, we should expect the bad marks to accumulate significantly more on the delegate who is actually responsible for the front running rather than the ones who were just unlucky enough to be right before or after that bad delegate.
But the problem with the above approach is that an attacker can easily frame an honest delegate for front running to try to get them voted out, which basically compromises the entire purpose of statistical analysis for catching misbehaving delegates. An attacker could craft each of the transactions themselves, with one bid/ask pair front running the market/limit order, and submit them to the network simultaneously hoping they all get included in the same block produced by their target delegate. If they could do this enough, perhaps they could make it appear as if it was that target delegate that was misbehaving. I tried to think through various fixes for this, but ultimately I don't think anything works very well.
So now I am going back to my original idea that a two stage process is necessary if we want market/limit orders. We could cut it down to 20 seconds rather than 50 seconds though. It just means the probability of a market/limit order not being accepted fully into the blockchain goes up, which isn't a big deal because one can just redo the transaction for another tiny fee. WYAIWYG orders could also coexist and these wouldn't have such strict timing requirements because users suffer no loss from any potential front running of these orders anyway.
So the idea is that the important details of the order transaction (basically the quantities and the price limit) would be encrypted with some secret originally known only to the transaction creator. The transaction with encrypted info would be submitted to the network and if it was a valid transaction (within the constraints of the information made available) and had the appropriate fee it would be accepted into a block. After confirming the order was accepted into the block, the transaction creator's client would then have to automatically and quickly submit the second part of the transaction which referred to the first one already accepted into the block and provided the secret that decrypted the encrypted information in the first transaction (this transaction could have no fee). If this second transaction was not submitted into the block right after the block containing the first transaction, then that entire order becomes void. In that case, the transaction creator has to try again after evaluating the market to see if they still want to use the same exact order. If the second transaction is included in the very next block, then the order is activated (assuming it is actually valid) at that time. In order to prevent front running, WYAIWYG orders will also need to be delayed by one block: the order becomes activated the block after the block they are included in. However, activated WYAIWYG orders could all be processed before any activated market/limit orders. This would prevent anyone on the network from being able to use a market/limit order to front run a WYAIWYG order (assuming the WYAIWYG order gets accepted into the very next block after it was broadcast). However, a series of WYAIWYG orders could still be used to front run the WYAIWYG order even though it would not be a sure thing for anyone who is not the block-producing delegate (since they could have no guarantees about the order the WYAIWYG orders are processed in). And again, users using WYAIWYG orders shouldn't really be complaining about front running anyway. If front running really bothers them, they would have to use the more timing sensitive market/limit orders instead.