For the defense against the "optimization attack" the only speed tradeoff I can think of is centralization. Full SolidCoin-style trusted-node verification every second block would work, at least for this aspect. That was actually my first approach, but I was looking for a tradeoff which preserved decentralization. Perhaps there is a way to federate the trusted nodes along the lines Ben Laurie proposed with his
mintettes. Centralization would simplify many aspects of the design, though.
Using the mintettes doesn't solve the 51% attack, it just moves it from the pool of all participants to a smaller hand selected pool of participants. It still requires that a majority of the mintettes be honest or the protocol breaks. The very nature of distributed rulesets makes them vulnerable to collusion, because that breaks the underlying assumption that the participants are not acting as a monolithic entity against the protocol.
I also believe the "51% attack" is misnamed. If the majority of the participants in Bitcoin agree to a protocol change, it changes. That is the process for adding positive changes to the system, but it is also a process from which negative changes can result (double spends etc). Trying to enforce that only positive changes can result from 51% of the hashpower is like trying to legislate that people act responsibly. I don't believe it can be done with any efficacy.
I would watch Solidcoin carefully over the next few weeks. You may gain some insight as to what goes wrong when a trusted node system goes haywire.