Briefly describe dYdX V4 technical architecture

dYdX V4 will be an independent L1 blockchain with a fully decentralized off-chain order book and matching engine.

**Written by:**dYdX

Compile: IBCL

dYdX Chain V4 is the latest iteration of the dYdX protocol, which will consist of open source software. The version currently in production is called v3, v3 and past versions of dYdX have at their core smart contracts deployed to existing chains combined with centralized services hosted in the cloud.

v4 will be an independent L1 blockchain with a fully decentralized off-chain order book and matching engine. The dYdX chain will be based on the Cosmos SDK and the CometBFT PoS consensus protocol.

As we get closer to the launch of the v4 mainnet, we wanted to give you a glimpse of what the dYdX team is building. This article provides a high-level overview of the v4 architecture. Given that v4 is still under development there may be changes.

v4 system architecture

dYdX v4 is designed to be fully decentralized end-to-end. The main components broadly include protocols, indexers, and frontends. Each of these components will be provided as open source software. dYdX Trading Inc. will not run any components.

Agreement

The protocol is an L1 blockchain built on CometBFT and using the CosmosSDK. Node software is written in Go and compiled into a single binary. Like all CosmosSDK blockchains, v4 uses a proof-of-stake consensus mechanism.

The protocol will be supported by a network of nodes. There are two types of nodes:

• Validators: Validators are responsible for storing orders in an in-memory order book (i.e. off-chain and without committing to consensus), gossiping transactions to other validators, and generating new blocks for the dYdX chain through the consensus process. The consensus process will have validators take turns as proposers of new blocks in a weighted round-robin fashion (weighted by the amount of tokens staked to their nodes). Proposers are responsible for proposing the content of the next block. When an order is matched, proposers add it to their proposed block and start a consensus round. A block is considered committed and added to the blockchain if ⅔ or more validators (by stake weight) approve it. Users will submit transactions directly to validators.
• Full Node: A full node represents a process running a v4 application that does not participate in consensus. It is a node with a stake weight of 0, which does not submit proposals or vote on them. However, full nodes connect to the network of validators, participate in the gossip of transactions, and process each newly submitted block. Full nodes have a complete view of the dYdX chain and its history and are designed to support indexers. Some parties may decide (for performance or cost reasons) to run their own full nodes and/or indexers.

indexer

Indexer is a collection of read-only services whose purpose is to index and serve blockchain data for users in a more efficient and web2-friendly manner. This is done by using real-time data from v4 full nodes, storing it in a database, and making that data available to end users via websocket and REST requests.

While the v4 protocol itself is capable of exposing endpoints to service queries about some basic on-chain data, these queries tend to be slow because validators and full nodes are not optimized to handle them efficiently. Additionally, excessive queries to validators can impair their ability to participate in consensus. For this reason, many Cosmos validators prefer to disable these APIs in production. This is why it is important to build and maintain indexers and full nodes separate from validators.

Indexers will use Postgres database for on-chain data storage, Redis for off-chain data storage, and Kafka for on-chain/off-chain data consumption and streaming to various indexer services.

front end

To build an end-to-end decentralized experience, dYdX is building three open-source frontends: a web application, an iOS application, and an Android application.

• Web Application: The website will be built using Java and React. The website will interact with Indexer via API to get off-chain order book information and send trades directly on-chain. dYdX will open source the front-end code base and related deployment scripts. This will allow anyone to easily deploy and access the dYdX frontend to/from their own domain/hosted solution via an IPFS/Cloudflare gateway.
• Mobile: iOS and Android apps are built using native Swift and Kotlin respectively. The mobile app will interact with the indexer in the same way as the web app and send transactions directly to the chain. The mobile application will also be open source, allowing anyone to deploy the mobile application to the App Store or Play Store. Specifically for app stores, deployers need to have a developer account and a Bitrise account to complete the app submission process.

Order Lifecycle

Now that we have a better understanding of each component of the dYdX v4, let's take a look at how it all fits together when placing an order. When placing an order in v4, it will follow the following process:

1. Users transact on a decentralized front end (e.g. a website) or via an API
2. The order is routed to the validator. That validator gossips about the transaction to other validators and full nodes to update their order books with the new order.
3. The consensus process selects a validator as the proposer. Selected validators match the order and add it to the next proposed block.
4. The proposed block continues through the consensus process. a. If ⅔ of validators vote to confirm the block, the block will be committed and saved to the on-chain database of all validators and full nodes. b. If the proposed block does not succeed in reaching the ⅔ threshold, the block will be rejected.
5. After a block is committed, updated on-chain (and off-chain) data is streamed from full nodes to indexers. The indexer then provides this data via API and Websockets to the front end and/or any other external service that queries this data.

The flow above is a high-level overview of how orders/data move through v4. As the v4 mainnet launch approaches, we will delve further into the protocol, indexers, and various front-end infrastructure in subsequent blog posts.