Ethereum X's
Technical solution

DAG Network

In a conventional blockchain protocol, transactions are validated within blocks. The validation process takes a certain time as the miners need to solve the proof-of- work problem. The groups of transactions have to be compiled together, the merkle tree of their hash ensuring the integrity of the blockchain. As the number of transactions increases, the time needed for a block to be filled up increases as well. It is now common to wait several minutes until a new block is created so that the transactions are validated. This waiting queue creates a backlog of transactions, and the only way to make your transaction validated on the blockchain is to pay a high transaction fee, which will attract and incentivise the miners to prioritise your tran-saction. Transaction speed, blockchain scalability, fees and mining process are then closely linked one to each other.

In the protocol proposed for Ethereum X, transactions are not grouped within blocks but lin-ked one to others. Each transaction validates one or more previous transactions and there-fore carries the proof-or-work and the hash to one or more previous transactions. This data structure is called a Directed Acyclic Graph (DAG) of transactions. A challenge with the DAG approach is to prevent all new transactions from referencing the same set of parent transac-tions, which would degenerate the DAG into an exploding tangle with a high degree of entropy. Abstractly, the DAG must not increase in «width» but in «length». It must stay in a cylindrical tangle shape. A chain of DAG has therefore the following properties :

  • All non-parent nodes are linked k times
  • The chain length is proportional to the original node count by a factor close to 2k
  • A DAG that has more than 2k nodes can be cut in two separate DAG having the same pro-perties. Each half has a factor k which is close to the original k factor


Figure 1: A 'contained' Directed Acyclic Graph of transactions

Our DAG protocol solves an important cryptographic problem. Double-spending is impossible as a transaction receives more than one approval. It is therefore accepted by the system with a higher level of confidence than a conventional blockchain. Furthermore, the DAG network is asynchronous. Transactions do not need to wait to be grouped and validated together, hence a shorter processing time. However, this feature is a double edged-sword. As transac-tions are validated independently, nodes do not need to communicate and to achieve a global consensus. More than having an eventual side-chain in a conventional blockchain architec-ture (which will be rejected by the system), it may result in a greater amount of conflicting transactions. Nodes then need to assess which transactions have to be rejected. To solve this problem, an algorithm similar to the one used by IOTA is implemented*. After running the algorithm, the transaction with the highest number of selections will be kept in the network. The other one will become an orphan. The algorithm needs to run 100 times to be optimal. For instance, if a transaction is selected 95 times after these runs, the transaction is said kept with a 97% interval confidence.

* The algorithm is described in the following way:

  1. Consider all sites on the interval [W,2W], where W is reasonably large.
  2. Independently place N particles on sites in that interval 30.
  3. Let these particles perform independent discrete-time random walks «towards the tips», meaning that a transition from x to y is possible if and only if y approves x
  4. The two random walkers that reach the tip set first will sit on the two tips that will be approved. However, it may be wise to modify this rule in the following way: first discard those random walkers that reached the tips too fast because they may have ended on one of the «lazy tips».
  5. The transition probabilities of the walkers are defined in the following way: ify approves x(y− > x), then the transition probability P


Our DAG technology also enforces smart contracts. Scripts can be implemented within the transaction headers and be enforced when conditions are met. Our solution can be seen as an advanced IOTA-like platform but with smart contracts enforcement, or as an Ethereum blockchain but scalable. Hence the name Ethereum X

Ethereum X’s transactions process

Prior to being written in the DAG distributed ledger, incoming transactions will be handled by our de-centralised backend platform. We are using IPFS (InterPlanetary File System), which means we are never centralising information. One of the main flaw of several blockchain solutions is that they communicate with their users through a simple web API before registering the transaction in the blockchain. This creates a point of centralisation and erases the benefit of the blockchain. Com-bining our DAG technology with IPFS allows our system to have no single point of failure.

A transaction will be therefore processed as follow:

  1. Request from the debit network is handled through IPFS
  2. Smart contract functions on the DAG network are triggered
  3. Transaction is registered on the DAG distributed ledger
  4. Respond to the debit network within a maximum of 1s

Ethereum X’s Maturity

Ethereum X DAG technology will be released in its stable version around Q4 2018. Meanwhile, we would like to offer our community the oppor-tunity to support us through the ETHX ERC20 token. ETHX holders will be credited the same amount of tokens once the DAG will be live.

A minimum viable product (MVP) of the DAG distributed ledger will be released earlier. We will proceed to a 3-month phase of beta tests in Q3 2018. Users with basic knowledge of distri-buted ledger architecture, payment APIs, smart contracts and IPFS will be selected to test the core features of our MVP (smart contracts, money transfers, payments by card). The first Ethereum X credit cards will be issued for this purpose.