In this post, I'll propose what I see as a practical design for a trustee-based system.
I propose a hybrid two-tiered system. The higher tier is a single trustee that generates blocks using txsets provided by the lower tier. The lower tier is responsible for generating txsets using a random (Poisson) process. All online nodes participate in generating txsets using difficulty-adjusted proof-of-stake. A txset consists of a proof-of-stake, a parent block hash, a list of transactions, and a signature by the key that generated the proof-of-stake. When a txset is generated, it's broadcast (of course, to avoid abuse of the broadcast communication path, all nodes must validate the stake, signature, and transactions before propagating the txset).
The trustee must include exactly TXSET_QUORUM txsets in a block; otherwise the block is invalid. Further, the transactions included in the block must be precisely equal to the set of transactions that occur at least TXSET_PLURALITY times in the block. TXSET_QUORUM is a tradeoff: Increasing it increases security, but costs broadcast bandwidth and blockchain storage. I suggest TXSET_QUORUM = 8. TXSET_PLURALITY is also a tradeoff. A trustee with connections to many wealthy coin holders will be able to front-run if they and their allies are able to generate TXSET_PLURALITY different stakes. Thus, increasing TXSET_PLURALITY makes front-running harder for the trustee. The tradeoff is that a larger TXSET_PLURALITY delays transactions, since they are required to saturate the network further before they become eligible to be included in a block. I suggest TXSET_PLURALITY = 5. (As its name suggests, there is no intrinsic reason why TXSET_PLURALITY >= TXSET_QUORUM / 2, even though my suggested value obeys that inequality).
In order to pull off a selective deafness attack -- especially over multiple blocks -- a trustee would have to control an enormous percentage of the network's online coins. Indeed, such consensus would be needed that a successful maneuver might be better described as "the trustee's desired protocol change was voluntarily adopted" than "the trustee carried out a successful attack."
Since txsets are generated randomly, it is possible for txsets to be generated too slowly for TXSET_QUORUM blocks to be available when the trustee wishes to generate the next block; under these circumstances, the trustee has no choice but to delay the next block until more txsets become available. (One possible cause of slow txset generation include bad luck in txset generation. Another possible cause is a downward txset generation capacity fluctuation that isn't yet reflected in the difficulty.) To mitigate the effect of slow txset generation, the generation rate of txsets can be increased so that the expected number of stakes generated in the desired block interval is TXSET_OVERGEN * TXSET_QUORUM. Like the other parameters I've discussed, TXSET_OVERGEN represents a tradeoff: Increasing TXSET_OVERGEN reduces the probability that blocks are late due to insufficient txsets, but reduces the percentage of the lower layer that a trustee must control in order to effectively dictate which transactions will be included in a block. I suggest TXSET_OVERGEN = 1.25.
My proposal has some protection against network splits: If a split occurs, then txset generation capacity will greatly slow on the "wrong" side of the split. If the split's resolved before the timeout interval, no fork will be created. If a substantial fraction of the online coins prior to the split are on the trustee's side of the split, then block generation will continue at a reduced rate. If the split's resolved after the timeout interval, there will be a fork, which will be resolved in favor of the side of the split that generated the longer chain. Which, due to the timeout interval, will be the pre-split trustee's side of the split if the split is resolved quickly. A longer split would be resolved in favor of whichever side of the split has more online coins, hence txset generation capacity.
A couple other details: Each txset is required to be consistent, e.g. cannot contain double spends. But since the block is a combination of txsets, the block may end up containing double spends; the trustee can't remove them because they can't override the decision of the txsets. I propose the following solution: Double-spend transactions resulting from txset combination are allowed in a block, but they turn into no-ops, and may be pruned once they are old enough to no longer be needed to validate the actions of the trustee.
Since transactions are not necessarily commutative and associative, transactions should be sorted according to some fixed deterministic order. In particular, the trustee should not be able to control the order in which transactions execute. I propose executing transactions in order of descending fee per byte (thus higher fee-paying transactions go first), with H(cur_txn + prev_txn) used to break ties, where cur_txn is the hash of the current transaction and prev_txn is the hash of the previously executed transaction (or all zeros if the tie is for the first transaction to be executed).
Also, it is possible to optimize the storage of txsets in a block, since we know that each txset's transactions are a subset of the block's transactions. For each transaction in the block, create txset_inclusion_mask, a value of TXSET_QUORUM bits indicating which txsets included this transaction. (With the suggested parameter value TXSET_QUORUM = 8, txset_inclusion_mask will be a single byte.) Then the txsets and their Merkle hash can then be reconstructed from the block's transaction list and the txset_inclusion_mask values. The Merkle hash is dependent on the ordering of the txset's transaction list, but we can simply require txsets to list transactions in sorted order.
With the above optimization, the overall storage requirements of my proposal are quite modest: A constant per-block overhead of 8 proofs-of-stake and 8 signatures, along with a one-byte increase in transaction size.