Introduction
An overview of DYDX (dYdX Chain)
In the section below we discuss how dYdX Chain validators would credit dYdX Chain user accounts with
DYDX, if the dYdX community decided through dYdX governance to replace the GovernanceStrategy smart contract with the GovernanceStrategyV2 smart contract.If a user interacts with the
wethDYDX Smart Contract before a certain cut-off date prior to the genesis of the dYdX Chain (“Genesis”), the amount of ethDYDX tokens sent by the user to the wethDYDX Smart Contract would be registered as event information of the wethDYDX Smart Contract. At this point, the user’s dYdX Chain wallet cannot be allocated with DYDX tokens because the dYdX Chain would not exist yet.
%20(2).png?alt=media&token=adc12c8a-fd59-4e2a-8f2d-2fc2209a7f97)
If a user interacts with the
wethDYDX Smart Contract after Genesis, then each dYdX Chain validator participating in the consensus process would read the event information of the wethDYDX Smart Contract and allocate DYDX tokens on the dYdX Chain to a given user’s dYdX Chain address based on the corresponding amount (1-1) of ethDYDX tokens that the user sent to the wethDYDX Smart Contract. Note, a user who interacts with the wethDYDX Smart Contract after the relevant cut-off time referred to above but before Genesis would be credited with L1 dYdX Chain tokens by the dYdX Chain validators in the blocks confirmed after Genesis.
%20(3).png?alt=media&token=21a3e186-3070-4438-87b7-cbe282002c2d)
At Genesis, the deployer of the dYdX Chain open source software will need to select a cut-off time before Genesis, Ethereum block height
H. Any bridging that occurred before block height H can be considered to be included in Genesis. Any bridging that occurs after Ethereum block height Hwill be credited in a later dYdX Chain block after Genesis. Each dYdX Chain validator will have to understand which events have or haven’t occurred on the Ethereum blockchain. Validators can do this by making RPC calls to an Ethereum node to get relevant logs. dYdX Chain validators should only process
finalized blocks.Validators will need to provide Ethereum RPC endpoint as a flag in the start command, instead of in a config file. Eventually, the URL of the node can be stored in the configuration file of the given validator. Ideally, this node is run by the validator themselves, but it could also be a hosted node from Alchemy or Infura. Ideally, to achieve a decentralized network, no more than 1/3 of the stake weight should use any one centralized service.
There would be a new injectable transaction that dYdX Chain validators can add in their blocks that mints tokens to the dYdX Chain as long as there is a corresponding event on Ethereum. dYdX Chain validators should only validate blocks with valid transactions (i.e., if they have also seen this event finalized on the Ethereum blockchain).
Each transaction should match (then increment) the
eventId which is kept in dYdX Chain state so that no events are skipped (without manual intervention) and only one integer is needed to track state for this module (limiting the amount of state needed for the module). The eventId should be set to some non-zero number at genesis to prevent replaying the events that were already added at genesis.