Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Mechanism design
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Foundations== ===Mechanism=== A game of mechanism design is a game of private information in which one of the agents, called the principal, chooses the payoff structure. Following {{harvs|txt|last=Harsanyi|year=1967|author-link=John Harsanyi}}, the agents receive secret "messages" from nature containing information relevant to payoffs. For example, a message may contain information about their preferences or the quality of a good for sale. We call this information the agent's "type" (usually noted <math>\theta</math> and accordingly the space of types <math>\Theta</math>). Agents then report a type to the principal (usually noted with a hat <math>\hat\theta</math>) that can be a strategic lie. After the report, the principal and the agents are paid according to the payoff structure the principal chose. The timing of the game is: # The principal commits to a mechanism <math>y()</math> that grants an outcome <math>y</math> as a function of reported type # The agents report, possibly dishonestly, a type profile <math>\hat\theta</math> # The mechanism is executed (agents receive outcome <math>y(\hat\theta)</math>) In order to understand who gets what, it is common to divide the outcome <math>y</math> into a goods allocation and a money transfer, <math>y(\theta) = \{ x(\theta), t(\theta) \}, \ x \in X, t \in T </math> where <math>x</math> stands for an allocation of goods rendered or received as a function of type, and <math>t</math> stands for a monetary transfer as a function of type. As a benchmark the designer often defines what should happen under full information. Define a [[social choice function]] <math>f(\theta)</math> mapping the (true) type profile directly to the allocation of goods received or rendered, :<math>f(\theta): \Theta \rightarrow Y</math> In contrast a '''mechanism''' maps the ''reported'' type profile to an ''outcome'' (again, both a goods allocation <math>x</math> and a money transfer <math>t</math>) :<math>y(\hat\theta): \Theta \rightarrow Y</math> ===Revelation principle=== {{main|Revelation principle}} A proposed mechanism constitutes a Bayesian game (a game of private information), and if it is well-behaved the game has a [[Bayesian Nash equilibrium]]. At equilibrium agents choose their reports strategically as a function of type :<math>\hat\theta(\theta)</math> It is difficult to solve for Bayesian equilibria in such a setting because it involves solving for agents' best-response strategies and for the best inference from a possible strategic lie. Thanks to a sweeping result called the revelation principle, no matter the mechanism a designer can<ref>In unusual circumstances some truth-telling games have more equilibria than the Bayesian game they mapped from. See Fudenburg-Tirole Ch. 7.2 for some references.</ref> confine attention to equilibria in which agents truthfully report type. The '''revelation principle''' states: "To every Bayesian Nash equilibrium there corresponds a Bayesian game with the same equilibrium outcome but in which players truthfully report type." This is extremely useful. The principle allows one to solve for a Bayesian equilibrium by assuming all players truthfully report type (subject to an [[incentive compatibility]] constraint). In one blow it eliminates the need to consider either strategic behavior or lying. Its proof is quite direct. Assume a Bayesian game in which the agent's strategy and payoff are functions of its type and what others do, <math>u_i\left(s_i(\theta_i),s_{-i}(\theta_{-i}), \theta_{i} \right)</math>. By definition agent ''i'''s equilibrium strategy <math>s(\theta_i)</math> is Nash in expected utility: :<math>s_i(\theta_i) \in \arg\max_{s'_i \in S_i} \sum_{\theta_{-i}} \ p(\theta_{-i} \mid \theta_i) \ u_i\left(s'_i, s_{-i}(\theta_{-i}),\theta_i \right)</math> Simply define a mechanism that would induce agents to choose the same equilibrium. The easiest one to define is for the mechanism to commit to playing the agents' equilibrium strategies ''for'' them. :<math>y(\hat\theta) : \Theta \rightarrow S(\Theta) \rightarrow Y </math> Under such a mechanism the agents of course find it optimal to reveal type since the mechanism plays the strategies they found optimal anyway. Formally, choose <math>y(\theta)</math> such that : <math> \begin{align} \theta_i \in {} & \arg\max_{\theta'_i \in \Theta} \sum_{\theta_{-i}} \ p(\theta_{-i} \mid \theta_i) \ u_i\left( y(\theta'_i, \theta_{-i}),\theta_i \right) \\[5pt] & = \sum_{\theta_{-i}} \ p(\theta_{-i} \mid \theta_i) \ u_i\left(s_i(\theta), s_{-i}(\theta_{-i}),\theta_i \right) \end{align} </math> ===Implementability=== {{Main|Implementability (mechanism design)}} The designer of a mechanism generally hopes either * to design a mechanism <math>y()</math> that "implements" a social choice function * to find the mechanism <math>y()</math> that maximizes some value criterion (e.g. profit) To '''implement''' a social choice function <math>f(\theta)</math> is to find some transfer function <math>t(\theta)</math> that motivates agents to pick <math>f(\theta)</math>. Formally, if the equilibrium strategy profile under the mechanism maps to the same goods allocation as a social choice function, :<math>f(\theta) = x \left(\hat\theta(\theta) \right)</math> we say the mechanism implements the social choice function. Thanks to the revelation principle, the designer can usually find a transfer function <math>t(\theta)</math> to implement a social choice by solving an associated truthtelling game. If agents find it optimal to truthfully report type, :<math>\hat\theta(\theta) = \theta</math> we say such a mechanism is '''truthfully implementable'''. The task is then to solve for a truthfully implementable <math>t(\theta)</math> and impute this transfer function to the original game. An allocation <math>x(\theta)</math> is truthfully implementable if there exists a transfer function <math>t(\theta)</math> such that : <math>u(x(\theta),t(\theta),\theta) \geq u(x(\hat\theta),t(\hat\theta),\theta) \ \forall \theta,\hat\theta \in \Theta</math> which is also called the '''incentive compatibility''' (IC) constraint. In applications, the IC condition is the key to describing the shape of <math>t(\theta)</math> in any useful way. Under certain conditions it can even isolate the transfer function analytically. Additionally, a participation ([[individual rationality]]) constraint is sometimes added if agents have the option of not playing. ====Necessity==== Consider a setting in which all agents have a type-contingent utility function <math>u(x,t,\theta)</math>. Consider also a goods allocation <math>x(\theta)</math> that is vector-valued and size <math>k</math> (which permits <math>k</math> number of goods) and assume it is piecewise continuous with respect to its arguments. The function <math>x(\theta)</math> is implementable only if :<math> \sum^n_{k=1} \frac{\partial}{\partial \theta} \left( \frac{\partial u / \partial x_k}{\left|\partial u / \partial t\right|} \right) \frac{\partial x}{\partial \theta} \geq 0 </math> whenever <math>x=x(\theta)</math> and <math>t=t(\theta)</math> and ''x'' is continuous at <math>\theta</math>. This is a necessary condition and is derived from the first- and second-order conditions of the agent's optimization problem assuming truth-telling. Its meaning can be understood in two pieces. The first piece says the agent's [[marginal rate of substitution]] (MRS) increases as a function of the type, :<math>\frac \partial {\partial \theta} \left( \frac{\partial u / \partial x_k}{\left|\partial u / \partial t\right|} \right) = \frac{\partial}{\partial \theta} \mathrm{MRS}_{x,t}</math> In short, agents will not tell the truth if the mechanism does not offer higher agent types a better deal. Otherwise, higher types facing any mechanism that punishes high types for reporting will lie and declare they are lower types, violating the truthtelling incentive-compatibility constraint. The second piece is a monotonicity condition waiting to happen,{{Clarification|date=July 2024}} :<math>\frac{\partial x}{\partial \theta} </math> which, to be positive, means higher types must be given more of the good. There is potential for the two pieces to interact. If for some type range the contract offered less quantity to higher types <math>\partial x / \partial \theta < 0</math>, it is possible the mechanism could compensate by giving higher types a discount. But such a contract already exists for low-type agents, so this solution is pathological. Such a solution sometimes occurs in the process of solving for a mechanism. In these cases it must be "[[Mechanism design#Myerson ironing|ironed]]". In a multiple-good environment it is also possible for the designer to reward the agent with more of one good to substitute for less of another (e.g. [[butter]] for [[margarine]]). Multiple-good mechanisms are an area of continuing research in mechanism design. ====Sufficiency==== Mechanism design papers usually make two assumptions to ensure implementability: <math>\frac{\partial}{\partial \theta} \frac{\partial u / \partial x_k}{\left|\partial u / \partial t\right|} > 0 \ \forall k</math> This is known by several names: the [[single-crossing condition]], the sorting condition and the Spence–Mirrlees condition. It means the utility function is of such a shape that the agent's [[Marginal rate of substitution|MRS]] is increasing in type.{{Clarification|date=July 2024}} <math>\exists K_0, K_1 \text{ such that } \left| \frac{\partial u / \partial x_k}{\partial u / \partial t} \right| \leq K_0 + K_1 |t|</math> This is a technical condition bounding the rate of growth of the MRS. These assumptions are sufficient to provide that any monotonic <math>x(\theta)</math> is implementable (a <math>t(\theta)</math> exists that can implement it). In addition, in the single-good setting the single-crossing condition is sufficient to provide that only a monotonic <math>x(\theta)</math> is implementable, so the designer can confine his search to a monotonic <math>x(\theta)</math>.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)