Analysis and Proposals on dYdX Chain and DYDX Tokenomics

Proposals
75

Hey all, Mag from Skip here.

I understand that reducing the validator set would have harmful effects - namely validators would get cut out of the active set. I’m not here to comment on that (it makes me sad), only to comment on the technical side after years of working deep within the Comet codebase.

Reducing the number of validators would definitely speed up dYdX. There is no honest technical argument to believe otherwise. Centralized systems are the fastest, and as a network approaches a centralized system, it will speed up. The reality is that the gossip factor of Comet-based data (e.g. txs, votes, blockparts) is extremely high, so any additional data gets flooded around the network multiple times. With dYdX especially, which uses Skip:Connect (and therefore circulates heavy Vote Extension packets), there is a ton of data on the gossip network. The more validators there are, the more gossip there is, as each validator regossips the data it receives. This can throttle a network by preventing votes, proposals, and blockparts from reaching the selected proposer, who will effectively wait for the network to catch up.

Cutting down the number of validators will reduce the amount of traffic in the gossip network, will reduce the number of validators required to vote on committing blocks/proposals, and will concentrate stake into the remaining validators that are not cut. This will improve network latency in a couple ways:

  1. On average, there will be a lower minimum number of validators from which votes are required to reach the 2/3 threshold, and so blocks will progress faster
  2. If the validators are colocated, the latency between each peer will be much smaller, effectively increasing the gossip throughput of the network.
  3. There will be significantly less data in the gossip network overall.
  4. There is significantly decreased chance that the proposer selected is a non-functioning validator (the risk of which increases as there are more validators)

Now, there are many other ways to reduce the latency / block time of a network, that are currently being worked on by the Informal team (and the Skip team) - including mempool performance improvements, reducing the size of vote extensions, direct peering amongst validators, etc. These are not ready, but will be helpful to achieve the same thing. This does not change the fact that decreasing the number of validators and colocating them will definitively lower blocktimes and latency - it’s just a technical reality.

2 Likes