Given discussions around shortening the slot times of Ethereum, conversations around geographic decentralisation seem more pressing than before. While I don’t have any answers on the impact of reducing the slot time specifically, I have been privy to many conversations about geographic decentralisation and am aware of several ongoing workstreams on the topic. To help stimulate more research into this complex topic, I thought I would share some of the different angles I’ve heard people take on the topic. None of them are mine and none of them are conclusive or comprehensively consider all relevant incentives.
I am writing under the assumption that you agree that geographic decentralisation is important. For more on that, this post from Phil provides more motivation.
Ideas from discussions with: Phil and many other Flashbots folks, Ciamac Moallemi, Mallesh Pai, Max Resnick, Pranav Garimidi, RIG i.a.
Definitions
I will not try to establish a canonical definition of geographic decentralisation, largely because I’m not sure what the best one is. One high level idea is relatively clear: a network in which reducing latency to other agents is always very profitable, is much more likely to collapse to a single point, than a network in which reducing latency has less benefit. Similarly, a network in which nodes that are “far away” have less influence on key functionality, is more centralising than one in which that is less true. The assumption is that there will always be some benefit to being located in one place or another, but if the benefit is small, it may be outweighed by other factors.
There are many ways to formalise this. Here is one suggestion from Phil:
One way to differ from this definition is to consider changes to only one player while everyone else is held fixed or to consider coalitions deviating.
Two caveats:
- Talk about nodes literally moving is an easy way to refer to the larger implied problem of stake shifting from nodes in one region to nodes in another.
- “Geography” isn’t simply what you see on your map. “Emerging markets” have lower bandwidth ISPs, inter-data centre communication is very efficient. Obviously if a protocol requires more bandwidth or lower latency to a point than a region offers, that regions will not see any participation.
“Nearest K” Effect
In some settings, agents are incentivised to minimise the latency of some message exchange that needs to happen with K other agents. For example, in a simplified model of Ethereum consensus, a block proposer must ensure that at least K=n*2/3 of attesters attest to their block if they want their block to be included. Since their block payout grows with time that passes, they are incentivised to release the block as late as possible. If we assume that attesters simply vote according to clock time - “did the block arrive before t=4s?” - the proposer is incentivised to release their block early enough that the K’th attester probably sees it in time, but likely later than needed for the furthest attester to see it in time. Since attesters derive revenue from attesting to blocks (much more than they make from proposing in aggregate), the furthest attesters make less money. All else being equal, proposers with a lower distance to the 2/3th closest attester also make more money.
Of course, this is a simplified model. In reality, block inclusion is more probabilistic and attester cutoffs are local. Perhaps attesters that are far away can adjust their cutoff times. At which point, the question becomes: do they have enough time to get their votes to wherever they need to go given their local cutoff?
You can imagine a similar world with multiple-concurrent proposers (MCP). Let’s assume the game theory works out such that searchers are incentivised to send their transactions only to the proposer that’s closest to Binance (in Japan). In such a world, single proposers that are in Cape Town still see all searcher transactions. However, once you introduce multiple proposers and randomly sample them from the validator set, its unlikely that the Capetonian validator is the nearest to Binance when it’s selected, reducing revenue.
Information Colocation
Agents in a system may be compensated relative to the information that they have access to (e.g. low latency price information from Binance, or transactions from an OFA server). In many cases, the value of information decays as time goes by (e.g. the Eth price from last year tells you less than the ETH price a ms ago), or as more agents are able to act on it (e.g. more searchers trying to backrun the same transaction). In these settings, agents may be incentivised to minimise the latency at which they can receive information and act on it by sending a message to a destination. Here are some examples:
- (1:1) If a searcher is trying to minimise the latency at which they can read from Binance and send their transaction to a proposer, they want to locate their trading server anywhere on a straight line between Binance and the proposer
- (1:n) If a relay is trying to minimise the latency at which it can receive a signature from a proposer and propagate it to a set of validators that are at different locations, the optimal location for the relay server is next to the proposer
- (n:1) If a block builder is trying to receive as many transactions from endpoints over the world as possible before they send their block to a particular relay, the optimal location for the builder is next to the relay.
- (n:m) ?
One style of argument that has come up a few times, is that actors who want to differentiate themselves, may choose to colocate with different information sources than their competitors. E.g. assume Bitcoin prices on Binance and ETH ETF prices on the S&P are jointly predictive of ETH’s price on Ethereum. One could imagine an incentive for one trader to locate themselves next to Binance, and another next to the NYSE server. Similarly searchers trying to backrun user transactions may situate themselves next to different RPCs. This argument is often used to say that MCP would create decentralising tendencies as different proposers would specialise around different locations. Naturally, this kind of argument relies on a lot of details that have not yet been specified.
I should also acknowledge that it is definitely a simplification to think of actors as being located in a single place. The same actor can run multiple servers in multiple locations, but multiple servers cannot act all-knowingly of each other. They must either communicate or execute algorithms that their sibling servers can predict - e.g. a validator probably doesn’t want its signing key being used independently by two servers as it will most likely double sign and get slashed! Despite this simplification, this style of “shortest line” reasoning is not uncommon among searchers and block builders so there is some empirical validation.
Message Exchange
Fast communication can be valuable. Today, block building teams work very hard to shave off milliseconds from their block building algorithms. Now let’s say we want to geographically distribute block building somehow so that the process involves multiple entities in multiple locations.
A naive thing to do would be to take entities all over the world and have them run a protocol which requires many rounds of communication and a lot of data to be exchanged. In this world, the incentive for colocating is very large because every ms that’s shaved off inter-node latency is multiplied by the many rounds of communication.
A better protocol only requires one round of communication. An even better protocol (for geodecentralisation) allows and incentivises communication, but doesn’t place communication as a requirement for producing a block (e.g. where multiple nodes can produce blocks independently, but with some coordination).
This lens can also be applied to MCP. The simplified argument goes as follows: the most “valuable” (for some agent) block is always built by an actor that has full information about all transactions and total control over the block. Introducing MCP reduces the information and control available to any one proposer. This means there is value in the multiple proposers communicating to overcome this uncertainty (e.g. by omitting reverting transactions). MCP has therefore created an additional incentive to communicate with low latency between actors that we didn’t want to colocate in the first place. Hence MCP is geo-centralising. Again, this argument depends on a lot of details.
Location Detection
Another approach (understandably) attempts to avoid incentives as much as possible by seeking other means to ascertain the location of some nodes. Existing work attempts to do this by assuming an honest threshold of nodes and triangulating locations based on response times. Of course, a proponent of this approach must be able to explain what the incentives of these “honest” nodes are, in addition to how robust the protocol is within these assumptions.
Should one succeed in establishing a protocol that surfaces the location of nodes, one can use this information to incentivise nodes to spread out, or prohibit nodes clustering above a certain density.
Conclusion
Geography underpins our pursuit of neutral, decentralised systems. Geographic decentralisation is a complex topic, but an important one. It is also largely underexplored. You have the opportunity to do the research that moves us all forward, toward the world we envision.