Complexity of Mechanism Design Vincent Conitzer and Tuomas Sandholm Carnegie Mellon University Computer Science Department

Automated mechanism design Mechanism design = designing rules of game so that a good outcome happens although agents play strategically Idea: Solve mechanism design as an optimization problem automatically –Inputs: outcomes, type space, prior, designer’s objective –Output: optimal mechanism –Creating a mechanism for the specific setting (instance) at hand rather than a class of settings –Advantages: Can circumvent impossibility results Can be used even in settings that do not satisfy the assumptions of canonical mechanisms (e.g. quasilinear utility functions) Can lead to a greater value of the mechanism designer’s objective (or stronger notions of nonmanipulability) than canonical mechanisms Often designer has info about agents - silly to ignore General preferences Quasilinear prefs

Mechanism design In multiagent systems, agents may have conflicting preferences over different outcomes that can be chosen Preference aggregation works as follows: –The agents report their preferences (types); –Then, the preference aggregator chooses an outcome on the basis of the reported types. Unfortunately, naïve preference aggregation leads to false revelations (manipulation) –E.g. claiming that an outcome is extremely valuable to you though in reality you only prefer it slightly Mechanism design is the study of selecting outcome functions which aggregate the preferences in a desirable way while avoiding manipulation

Why restrict attention to nonmanipulable mechanisms? It is conceivable that there exists a mechanism that –Is manipulable, but –Leads to more desirable outcomes that any nonmanipulable mechanism, even when taking manipulation into account The Revelation Principle states this never happens: equally good nonmanipulable mechanisms can easily be found –Take a manipulable mechanism –From this, construct a new mechanism with an interface layer between the agents and the old mechanism An agents reports its type to the interface layer The interface layer (mis)reports the type strategically to the old mechanism, acting on the agent’s best behalf –Now the mechanism is nonmanipulable but gives the same outcomes

Automated mechanism design Mechanism design has traditionally focused on finding general mechanisms that are optimal for a large class of settings –E.g. Vickrey-Groves-Clarke mechanisms are perfect when Utility is transferable between agents (quasilinear preferences) The objective is to maximize social welfare (the sum of the agents’ utilities) Unfortunately, these general mechanisms do not cover many settings –Quasilinear preferences are quite unrealistic –Sometimes we do not wish to maximize social welfare but something else (e.g. auction revenue) This does not preclude us from finding mechanisms for specific settings that are not covered by general mechanisms –Oftentimes, we are given specific information about the possible outcomes, and the agents’ preferences In automated mechanism design, we use this information to generate an optimal mechanism on the fly

Advantages of automated mechanism design It can be used in settings where classical mechanisms do not apply It can outperform classical mechanisms on specific instances –Stronger concepts of nonmanipulability –More desirable outcomes It can be used to circumvent impossibility results stating there is no mechanism desirable over all preferences (such as the Gibbard- Satterthwaite theorem)

Requirements To do automated mechanism design, we need: –Formal definitions of the associated computational problems –Efficient algorithms for solving these problems Unfortunately, it turns out that for some computational mechanism design problems, efficient algorithms are unlikely to exist –Computational mechanism design can be NP-complete We will show how allowing for randomized mechanisms circumvents this problem

Defining the computational problem: Input An instance is given by –Set of possible outcomes –Set of agents For each agent –set of possible types –probability distribution over these types –utility function converting type/outcome pairs to utilities –Objective function Gives a value for each outcome for each combination of agents’ types E.g. social welfare –Restrictions on the mechanism Are side payments allowed? Is randomization over outcomes allowed? What concept of nonmanipulability is used?

Defining the computational problem: Output The algorithm should produce –a mechanism A mechanism maps combinations of agents’ revealed types to outcomes –Randomized mechanism maps to probability distributions over outcomes –Also specifies payments by agents (if side payments are allowed) – … which is nonmanipulable (according to the given concept) –By revelation principle, we can focus on truth-revealing direct-revelation mechanisms w.l.o.g. maximizes the expectation of the objective function

Single agent mechanism design Only one (type-reporting) agent All concepts of nonmanipulability coincide here –Difference in concepts of nonmanipulability comes from what agents are assumed to know about others’ types –Here there are no other agents! The (standard) social welfare function as an objective is easy here (no conflict) (Generalized) social welfare is still nontrivial –There is also an outside societal interest in the outcome –Outside society’s “type” (preferences over the outcome) is already known –We seek to maximize agent’s utility + outside societal utility This setting already highlights many computational issues

Summary: results on single-agent mechanism design No payments, no randomization: –NP-complete even with (generalized) social welfare (reduction from MINSAT) Payments, no randomization: –Easy with (generalized) social welfare – use VCG mechanism –NP-complete for general objective functions (reduction from INDEPENDENT-SET) No payments, randomization: –Easy trough linear programming (probabilities are variables) Payments, randomization: –Easy trough linear programming (probabilities, payments are variables)

Our results on the complexity of mechanism design Social welfare objective: General objective functions: payments no payments payments no payments Deterministic mechanism Randomized mechanism NP-complete (MINSAT) Polynomial time (Groves) Polynomial time (LP) These results hold even for just 2 agents Deterministic mechanism Randomized mechanism NP-complete (MINSAT) NP-complete (INDEPENDENT-SET) Polynomial time (LP) Polynomial time (LP) Polynomial time (LP)

More agents All the hardness results from single agent mechanism design generalize to more agents –In the reduction, simply add dummy agents with only 1 type –Even standard social welfare becomes NP-complete (without payment/randomization) Simply incorporate the “outside” component of generalized social welfare into a dummy agent Randomization still makes the problem easier –Again, we can solve the mechanism design instance with linear programming –The constraints now reflect the chosen notion of nonmanipulability (implementation in Bayes-Nash equilibrium, in dominant strategies…)

Conclusions on automated mechanism design We proposed an approach where mechanisms are designed on the fly for the setting at hand –Applicable in settings not covered by classical mechanisms –Can outperform classical mechanisms –Circumvents impossibility results about general mechanisms Formally defined the computational problem Analyzed its computational complexity –Various simple settings are NP-complete –Allowing for payments sometimes (not always) makes problem tractable –Allowing for randomization over outcomes always makes problem tractable Future research –What can be done with additional structure on preferences When are other representations more appropriate –What can be done with partial input? –Using mechanism design algorithms experimentally to infer general mechanisms –(Dis)proving mechanism design hypotheses by running automated mechanism design on randomly generated problem instances