Protocol Design

I have recently stopped describing myself as an “economist” and have begun using the phrase “protocol designer”. But what do I actually mean by that? In economics we already have the term “mechanism design”. This sub-discipline of economics begins with a captive set of participants and a central authority who imposes rules onto the players. In the traditional mechanism design setting the “problem” is already defined, for example, a monopolist wants to sell an item but does not know the value or a contract between a principal and an agent has to be constructed.

In contrast, I propose that protocol design concerns itself with creating the building blocks that support interactions that are yet to be defined by the participants. In fact, at its most ambitious and realistic, the protocol designer only has limited information on who will be utilizing these protocols. I envision a library of protocols that participants select from and a “platform” or a machine/server provides the infrastructure to run these protocols in a trustworthy manner. The platform is a record keeper, not a player: a server holding a tamper-evident log of requests and responses that participants have signed.

Thanks for reading Joachim Groeger! Subscribe for free to receive new posts and support my work.

The design focus is on supporting core primitives that we implicitly lean on in society: protocols that allow for repeated interactions between individuals, and protocols that generate and track reputation and therefore sustain cooperation.

Let’s be more precise. Imagine a simple protocol where two participants can trade favors across time. The platform helps track when favor requests are made and how the participants respond. In addition, there is a menu of policies, i.e. “behavioral rules”, that the platform provides to complete the protocol. The participants pick from this menu to help sustain cooperation and penalize deviation from cooperative outcomes for the specific context they are operating in.

A desirable property of protocols is that they be “composable”. The simplest approach is to allow chaining together of protocols. For example, the outcome of the favor trading game described above alters your ability to participate in other transactions downstream. You could be set at a disadvantage in a future voting game if you have not been a good partner in the favor trading game.

Ideally a protocol could eventually be modified: in the favor trading game policies can be modified by users and added to the shared menu. This is a closer embodiment of one of Ostrom’s rules on governing the commons: “Most individuals affected by the operational rules can participate in modifying the operational rules.” Existing protocols in the library can be used to implement these changes.

Ultimately, the configuration and collection of protocols becomes an institution. In my mind then an institution is a combination of protocols that allows the individual components of an institution to be revised and redesigned via new protocols instead of re-building the whole. This means adaptability of an institution is baked into the structure.

I think when I say “protocol design” most listeners will think of network protocols. The internet protocol, for example, stipulates the specific form a header (the structure that precedes the data being transmitted) has to take. For example the IP header:

This header has a specific structure that is described below

Everyone agrees to use this to identify payloads between machines. The interesting problem with the above is that fields can be “spoofed”. The “source field” (c0 a8 01 11 source = 192.168.1.17 in the above) is written by your machine. However, the user can “overwrite” that source information. You could transmit a packet, and then point the response to someone else by manipulating the source field. There is no substructure in this protocol that prevents lying. This is mostly an artifact of the original creators imagining a network of cooperative players. The protocol rules here are separate from incentives. In my view they have to be designed at the same time.

That is my key interest when thinking of protocol design. This is not just about creating a regular structure that participants agree to use. I am seeking designs that are robust to adversaries that might have the incentive to engage in untoward behaviors.

I want to build protocols that are designed to sustain truth-telling outcomes. Misrepresenting private information is to be avoided and we can sustain cooperation. The last one is the most compelling if you are building an ecosystem. A simple example of the latter will demonstrate how a well designed protocol can do this.

In many settings well designed protocols leave little room for lying. Let us go back to the favor trading example (the setup here leans on Mobius and Hauser & Hopenhayn). How would that protocol work? We have two people who have randomly arriving needs. When a person has a need they can ask their partner for a favor. Take two people Alice and Bob. The protocol is simple:

1. Each person gets an upper limit K for favors they can request

   1. There is a public “favor balance”, call it x which runs from -K to +K, where a negative balance means Alice owes more favors and a positive one means Bob owes more. At the beginning of the interaction x=0.

   2. After M periods of no activity, balances step towards zero by one unit each period. This only holds if no rejection of a valid request is outstanding.

2. Alice can request favor if x>(-K), Bob can request if x<K

3. Alice and Bob can help or reject a favor. Say Bob rejects a request, then Bob can not make any favor requests for a fixed number of days, say T days. Alice can continue to make requests, with each rejection Bob adds T days to his exclusion.

4. Exit is possible with some notice period N, but the platform will track how many outstanding rejections each person has. During notice the exiting party may not request and decay is frozen. Rejections during notice set the latch and are logged as rejection-during-notice.

This protocol has good incentives for long run favor trading and mimics much of the work on repeated games where strategies stipulate punishments when faced with deviation from a cooperative outcome.

Here is a typical path of play where Alice makes two requests and then hits her limit and then has to work off her debt to Bob eventually Bob owes her a favor.

Alice makes two requests, she hits her limit and has to work off the debt by providing favors in future rounds. A more complicated path is shown below where Bob rejects at t=5 and but then still helps after being punished. Eventually no needs arise and x→0, the decay function on debt takes over and makes sure things essentially reset to avoid a persistent imbalance.

In the second example above Alice and Bob are in good standing and could exit the relationship. Our server logs the full path of play allowing Alice and Bob (and possibly others, depending on granted permissions) to observe behavior. A balance of x=0 with the history of actions provides an informative signal on standing for Alice and Bob. Any data from this interaction can then be referenced by another protocol downstream. This is how chaining would be implemented in practice: the record of an interaction is logged by the server and then accessible to other participants and protocols. The incentive properties are obviously more complex with chaining. However, detailed logs allow the designer and participants to determine whether the protocols have to be updated or modified.

In mechanism design the game is fixed, whereas in protocol design participants construct the game from the set of protocols available on the server. Play is logged and rules can be revised for the next round of interactions. The protocol designer, without knowing in advance who the participants are, supplies the core pieces that participants assemble to support their interactions. Eventually the collection of protocols in active use form an institution. A mechanism is designed once. An institution has to be able to change.