Predictable Systems Can Fail
Every predictable system lends itself to attack. In a previous post we discussed Spotify's payout model. The existing payout framework lent itself very directly to exploitation. Part of the reason was that the rules were very predictable. The only uncertainty a bot farm faces is whether its activities will be detected. If they can evade detection they have essentially unlocked a deterministic money pump.
Few arenas illustrate this as cleanly as Formula 1. Since 2014 the FIA has required every car to carry a standardized fuel flow meter and capped fuel flow at 100 kg/h, the idea being that fuel flow scales roughly with engine power. The meter samples flow at a known, fixed rate of 2200 Hz. In 2019 Ferrari was suspected of exploiting this predictability through aliasing. By pulsing the fuel delivery system at a specific frequency, they could arrange for each sample to fall in a trough of the actual flow, while the peaks (which exceeded 100 kg/h) happened in the gaps the meter never observed. The engine ate the peaks and that translated to real power even though the time-averaged fuel flow could remain compliant.
The FIA never publicly confirmed the exploit but changed the rules anyway. And that is the more important point: the design was vulnerable regardless of whether anyone had exploited it. So they fixed the design rather than trying to catch cheaters.
What was the fix? Inject uncertainty into the system. The fuel pump trick worked because the sample rate was known to be 2200 Hz. A team could design against that specification and push fuel higher in the gaps between samples. What if the sample rate was not known? A team could eventually reverse engineer it by detecting how often samples were sent out. So the FIA encrypted the data. But what if you could defeat the encryption? So they randomized the sample timing so teams could no longer lock onto the phase. This is precisely what the FIA did: a combination of encryption and randomization. By randomizing the sampling frequency the teams could never find the right frequency for their fuel pumps.
Randomization as a design tool
So what is the broader design lesson? Randomization can be a useful ally even when it introduces uncertainty over outcomes.
Consider an organization run as a democracy where choices are agreed upon by majority vote. What happens in these settings? In general, we see a lot of activity outside of the election itself. Side payments, bribes, coalitions forming, promises to vote in favor of another person's policy. Everyone seeks ways of rigging votes in their favor.
How can we break this? One protocol is to introduce randomization. Randomly pick a subset of the total voting population, make them a sub-electorate, count only their votes. A lobbyist now faces a verification problem with two layers: they cannot check whether a voter actually voted as instructed, and they cannot check whether that voter was among the randomly selected sub-electorate whose votes were counted. The voter can plausibly claim "I voted as you asked but wasn't selected" regardless of what they actually did. Lobbying expenditure becomes a poor investment. This kind of mechanism has a longer tradition in the literature on sortition and lottocracy.
You could take this further and suggest that only one vote be looked at. This would be a random dictatorship: one person is chosen and they decide for everyone.
Random serial dictatorship
There is an extension of this dictatorial protocol to a multi-unit setting. Consider a hard allocation problem: 100 different items and 100 people with private preferences over them. How should I proceed?
A startlingly simple protocol does most of the work. Pick a person uniformly at random and let them take their favorite item. Pick another at random, let them take their favorite from what remains. Continue until everyone has an item. This is random serial dictatorship, and it has three virtues: it is strategy-proof (no one gains by lying about their preferences), every realization is Pareto efficient (no group of agents could trade to make everyone better off), and equals are treated equally (two agents with identical preferences face identical lotteries).
The reason it is strategy-proof is very direct. When your turn comes, you face some set of remaining items. That set is determined entirely by what the agents before you have already picked. Your report cannot expand or change that set. The only thing your report controls is which item from the set you walk away with. So why would you ever report anything other than your true favorite? You would just be picking a worse item from the same menu.
This logic holds for every position in the ordering and for every possible ordering. Truth-telling is dominant in every realization, so randomizing over orderings preserves the property. RSD is strategy-proof not despite being random but because the randomness is layered on top of a deterministic mechanism that is already strategyproof.
The design lesson
The instinct when designing mechanisms or protocols is to engineer in a manner that avoids uncertainty. A fully optimized, fully deterministic system is a system your adversary can study, reverse engineer, and exploit. The F1 teams could game the fuel meter because they knew exactly how it worked. The Spotify bot farms could game the payout model because they knew exactly how royalties were distributed. The lobbyists can game the vote because they know exactly whose vote to buy.
Randomization removes the fixed target. The adversary can still study the mechanism, but there is no stable specification left to attack. The cost is variance in outcomes. The return is a system that survives contact with people trying to break it.
Ansible Architecture designs incentive systems and interaction protocols for platforms and marketplaces.
