The "Slow Game" in Decentralized Protocols: Navigating High-Frequency Service Regulation with Low-Frequency Governance (WIP)

Protocol Design
1

Introduction

In the world of decentralized protocols, there’s an inherent tension between high-frequency service providers and their low-frequency regulators. At the core lies the challenge: how does a community effectively oversee and regulate service providers that operate at high speeds using a governance mechanism that, by design, takes its time?

Understanding the Tension

Traditionally, systems aim for harmony between service speed and oversight. However, in the decentralized space, there’s a deliberate decision to maintain a slower pace for governance. This ensures decisions are thoroughly vetted, deliberated upon, and agreed upon in consensus. Yet, the very agents it governs — service providers to the protocol — need to provide their services at much higher speeds for the network to fulfill its value.

Arthur-Merlin Protocols: A Primer

Before diving deeper, it’s instructive to turn to complexity theory. Here, Arthur-Merlin protocols provide an interesting insight. In these protocols:

  • Arthur, the verifier, is a probabilistic polynomial-time entity.
  • Merlin, the prover, has unbounded computational power.

Merlin seeks to convince Arthur of certain truths, even though Arthur might be skeptical due to Merlin’s superior computational abilities. Traditionally, Arthur is visualized as a single entity.

From Arthur-Merlin to Decentralized Communities and Permissionless Service Provisioning

Our situation with decentralized protocols mirrors the Arthur-Merlin dynamic but adds two forms of complexity:

  1. Arthur’s Decentralization: Instead of a singular entity, Arthur becomes a decentralized community. It’s within this community that we find solace in the “honest majority” assumptions, given its collective, consensus-driven nature.
  2. Powers Beyond Computation: Merlin isn’t just a powerhouse of computation. In our scenario, Merlin(s) provides package routing, matching, and other services and assurances about their performance to the network.

Directions for Proposed Governance Mechanism: Demonstration-Reward Protocol

To bridge this divide between the “slow” decentralized community and the “fast” service provider, we propose that the protocol:

  1. Reward Demonstrations: Encourage the community to showcase profitable attacks that go unnoticed when carried out by the fast-paced service providers. This brings vulnerabilities to light.

  2. Reward Detections: Compensate for the detection attacks. This makes it economically viable for fast actors to safeguard the system.

Both rewards should be inversely proportional to the number of teams who achieve a given demonstration or detection. This is both needed for anti-sybil mechanics, (through it does create a economic incentive for collusion between different red-teams) and to estimate the value of the attack.

Navigating the Challenges

  1. Authenticity Assessment: How do we gauge the genuineness of an attack or demonstration?
  2. Economic Balancing: Ensuring that rewards are substantial enough to encourage auditing, but that the costs this imposes on the network do not limit its appeal.

Directions for ongoing work

The intricate dance between high-frequency services and low-frequency governance in decentralized protocols will require careful planning and robust mechanisms. Drawing parallels with established theories, like the Arthur-Merlin protocols, offers a initial lens through which we can begin to approach these challenges. As we continue refining this approach, the ultimate goal remains: a resilient, secure decentralized network.

3 Likes
2

If I were forced to write a one line tl;dr of the “Economic Balancing” part, it would be

Let’s have better reward schemes for white hats to do vulnerability research!

Besides oversimplification, what am I missing?

Then, on the Authenticity Assessment-part, reproducibility seems to be the silver bullet—at least for “bad habits” of the fast-paced service providers, i.e., repetition of the same exploitation pattern. (Btw, maybe this is related to the idea of holding service providers “accountable” or making their behavior auditable via public, suitably anonymized data about their user interactions, right?) Now, decentralized Arthur should be able to audit/oversee at cost covered by the reward scheme while it should also be relatively cheap for service providers to be open to audits/oversight.

However, maybe I need to read up on what High-Frequency Service Regulation is actually. Or can you point me to a readers digest version?

3

Ideally we would like the “white hat” part to be superfluous. That incentives be such that all profit maximizing actors to publicize the vulnerabilities instead of using them, irrespective of their legal preferences.

Otherwise yes, the security of the network is a public good and we would like to structure the game so contributing to it is optimal. I do not think there is much practical work in the permisionless setting on this; many project use some form of hand picked committee gets to decide ex-post how severe a vulnerability was and it’s reward. Bringing this in protocol, and designing the protocol so that this is possible, is extremely greenfield research.

The legislative-judiciary control system has a much easier objective to some degree, since it is both permissioned, and trying to regulate a narrow domain. Supporting permissionless general applications, requires thinking through which guarantees can be made (this will be different than in the permissioned setting) and which ones cannot (and thus protocol and app incentive designs needs to take into account ). To illustrate, in tradfi often there is a requirement of matching a “global” best-offer price in execution as known at a central venue, and the regulator can ex-post examine if this held or not. In the permissionless setting the speed of light and the distribution of nodes means one cannot defined a central venue, and best-prices that can be observed are inherently “local”, so for example this kind of regulation needs at least some adaptation.

2 Likes
4

Notes (only roughly organized) from our brainstorming session, phrased in terms of open questions:

  1. Is anything other than time part of what dictates production possibility? What can we derive / bound solely from the ratio between the slow & fast game periods?
  2. How does slow game / fast game relate to dry game / wet game?
    A dry game is a game for which you can write a program (in principle) that would beat any human without a human training it. Example: chess.
    A wet game is a game for which you cannot write such a program; you would need human training. Example: Schelling point game e.g. “meet me in NYC”. Game play and strategies are dependent on social features of the world.
  3. Do we need a shared algorithm to compute a single scalar value to weight votes (in the slow game) in order to achieve consensus? Must this algorithm be ex ante (cannot incorporate information observed in the fast game) or can it be ex post (can incorporate information observed in the fast game)? If we don’t have a single algorithm, but have different algorithms with some correlation (a la heterogeneous security, overlapping trust networks), what are the conditions of slow game convergence?
  4. How long do you have to store information (particularly transcripts of fast game play, “what happened”)? What is the tradeoff between storage/bandwidth (which can be spent to track and store more granular partial ordering information) and the precision of measurements that the slow game can take of the fast game / bounds that the slow game can guarantee? When can you safely perform “garbage collection” of old metadata?
  5. The slow game proceeds in rounds. When do you start a round, and when can you say that you’re done with a round? Must the round length be determined ex ante, or can rounds “terminate early” if some (not-full-slow-game) checks indicate that the round must be speedier?
  6. If the equilibrium we want is that of a “contestable monopolist”, i.e. a monopolist set of fast game players whose actions are tightly constrained because of a credible threat to switch them out with the slow game, can we more specifically define and quantify what this equilibrium requires?
  7. Can we learn the appropriate round length by testing this measure of contestability? What risks might learning the round length (or mis-estimating at first) entail?
  8. Can we create a sort of “contestability seal” which could be broken periodically to prove that the slow game can still contest the fast game?
  9. Can we amortize the cost of playing the slow game (likely to be high bandwidth) into some smaller, more probabalistic checks which we can run more frequently, and which provide similar assurances over comparable lengths of time?
  10. Let’s say that there are two “cakes” in play - one for the surplus of the operator contestability game, and one for the surplus of the whole game. Which cake is at stake? Can we bound the surplus lost to the fast game, and what are the bounds?
5

An older write-up but this outlines recovery mode post-slashing a malicious operator.

Operator auction

If a previous operator has been slashed we begin the search for a new operator. We have an auction where users bid for the right to be the operator giving a deposit and the state from which they wish to begin.

After a certain time, the new operator will be selected based on the highest bid (above a certain minimum) with the most recent sidechain state.

recognize that the mechanism here may not be directly applicable or satisfy the properties we want with the “Slow Game”.

7

@nikete and I talked about some more areas of concern of the slow game last week. Here are some notes:

Purposes of the slow game

Incentivize fast actors to help enforce the rules decided upon in the slow game, by regulating each other.

Network Characteristics

One attack of fast actors lies in the insertion or censorship of e.g. intents or TXs

To monitor network characteristics effectively, fast actors need to be incentivized to cooperate on detection. Since detection will be lossy, punishment must be proportionally higher to sufficiently disincentivize defection.

Fast measurements

Since slow game actors can not directly observe fast interactions, but only aggregate results, it needs to recruit fast game actors by way of setting incentives.

Since the fast game has a high resolution, malicious actors have good tools to dynamically approximate the bounds dictated by the slow game.

Example: If a supposedly welfare maximizing service improves efficiency internally, but does not announce these improvements, it could extract the gains in efficiency instead of redistributing, at least for a while until the aggregate gets skewed enough for detection by the slow game. If fast actors are correctly incentivized, detection can happen much quicker. (Improving efficiency of services provided, especially if it is reproducible, should still be rewarded, but in some circumstance it might make sense to be auditable.)

Collusion

Collusion is (covert) out of protocol coordination of a subset of actors for the gain of the members of this subset, compared to the rest of the actors.

To effectively collude with other actors, one must prove a correlation between a legitimate, in protocol cryptographic identity with an out of protocol message.

This can be used to e.g. establish pseudonyms for collusion side channels or to verify that actions agreed upon by the colluding parties have been executed in protocol.

Thus, to credibly prove that collusion happened, it is necessary (and sufficient?) to prove the correlation of an in band identity to any out of band message.

The slow game needs to make it more profitable to detect and prove collusion, than to participate in it to extract surplus.

Slow Game Decomposition

Since fast games are decomposed into subsets of state according to the controllers responsible for them, we can also decompose (at least some layers of) the slow game along these lines.

Time in the slow game

Each slow game needs to find agreement on a canonical “wall clock” time. This can be low resolution but must be globally and undisputably observable, e.g. astronomical events like an equinox, moon phases. These can be used as ticks or to reset individual wall clocks of participants in regular intervals.

Ideally time independent commit reveal schemes are used in decision making, since we can’t regulate timing dynamics here.

Scale of slow game

The slow game needs to be large in the number of participants, s.t. that it becomes expensive for fast actors to reason about it.

2 Likes