Distributed Validator Technology

dYdX V4 will take the form of an L1 Blockchain built on top of CometBFT (a service that provides a Byzantine Fault Tolerant/Tendermint consensus engine for state-machine replication), and using CosmosSDK (an open-source framework for building multi-asset public Proof-of-Stake (PoS) blockchains - it can also be used to build permissioned Proof-of-Authority blockchains - but that’s another matter altogether which it out of scope). CometBFT is application-agnostic and will be handling two aspects of dYdX V4:

The Networking layer; and
The Consensus layer.

All in all the interplay between CosmosSDK and CometBFT looks something like this:

CometBFT uses Tendermit (this is also referred to as Byzantine Fault Tolerance/atomic broadcast - however, it is more colloquially known within the Cosmos ecosystem as Tendermit) - a detailed analysis of the Tendermint consensus mechanism can be found in the introductory paper written by Ethan Buchman, Jae Kwon and Zarko Milosevic here: https://arxiv.org/pdf/1807.04938.pdf.

The relevance of CometBFT with regard to Distributed Validator Technology lies in the fact that CometBFT adopts the use of validators to handle transaction bytes (nodes that are encharged with adding blocks of transactions to the blockchain they are implemented in regard to - in this case dYdX V4). These validators naturally interplay with the Tendermint Consensus Mechanism; which determines the order within which the validators produce blocks, and whether such blocks are valid (this is determined by virtue of a ⅔ agreement by other validators following two predetermined signature).

In the case of dYdX, (refer to: v4 Technical Architecture Overview - dYdX):

“validators will take turns as the proposer of new blocks in a weighted-round-robin fashion (weighted by the number of tokens staked to their node). The proposer is responsible for proposing the contents of the next block. When an order gets matched, the proposer adds it to their proposed block and initiates a consensus round. If ⅔ or more of the validators (by stake weight) approve of a block, then the block is considered committed and added to the blockchain. Users will submit transactions directly to validators.”

The concept of DVT was primarily popularized due to its inclusion in the Ethereum Roadmap by Vitalik Buterin. At a high level, DVT would allow for a cluster of persons (be it legal or natural persons), to run a single validator. This has been referred to by many in the industry as a way of adopting the Multisig ethos to validator technology; by decreasing single points of failure in regard to the validators forming part of an underlying consensus mechanism through the disbursement of responsibility in regard to the operation of a particular validator.

The barrier to entry to run a validator (which could be anything from technological requirements to minimum staking / self-staking requirements), could result in decreased numbers of validators operating V4 or, conversely, it could result in low-performing validators, which would have diminished chances of adequately partaking in the V4 consensus due to the weight-based round-robin nature of the consensus process.

Distributed Validator Technology could add to the security and decentralisation of dYdX V4 whilst helping in expanding the validator-set in a cost-efficient manner whilst increasing the aforementioned factors. From a security perspective, having a cluster of nodes running a distributed validator aims to reduce the element of a single point of failure inherent in a single validator having a significant amount of tokens staked/delegated to them (disbursement of operation = minimisation of risk in this case).

The purpose of this post is to introduce the concept to the community. I would highly suggest that @carlbergman and the Grants Program team consider putting up an RFP in relation to the above Conversely, it would also be interesting to discuss the above with @antonio considering that dYdX Trading will be undertaking the role of an external software developer for the Platform post-V4.

I look forward to hearing your thoughts!

1 Like

Good afternoon, @Immutablelawyer. Thank you for your thoughtful posts and lively debate.

All of these are valuable contributions that must be coordinated with the protocol deployment and stabilization goals.

An essay about Cosmos DVT potentials and problems is included here for future reference.

The fact that the validator on the DYDX Chain will be in responsible of both consensus and orderbook maintenance raises questions on our end. It will undoubtedly be considered after the chain is established and stable. We anticipate that MEV will be focused on before DVT.

2 Likes