Review of Conflux & TokenGazer AMA Meetup

On Dec. 27th, Conflux was invited to attend the online Q&A meetup host by TokenGazer, on which Dr. Ming Wu, CTO of Conflux, had in-depth discussions and shared his scientific thoughts with more than 100 participating researchers. On this meetup, the audiences were impressed by the technical advantages and development potentials of Conflux and developed a strong faith in Conflux’s future.

Below is the text summary of the meetup：

Q1: What is the difference between the DAG structure used by Conflux and the blockchain structure used by Bitcoin and Ethereum?

Ming Wu: This is a very principal question, which I would very much like to discuss in detail. Let me start with the efficiency limit of Bitcoin. According to some academic papers, in Bitcoin’s protocol, no matter how you adjust the block generation rate and the block size, you can never have both high efficiency and high safety at the same time.

What is the rationale underlying this fact? Imagine that we have two blocks, both generated by honest nodes. However, because of the network latency, the two blocks were not aware of each other’s existence during their generation. Therefore, they will be on different forks. Once added into different forks, the two blocks will find themselves in a life-and-death competitive relationship. One of them will be abandoned eventually. Unfortunately, the abandonment of blocks generated by honest nodes will cause a loss in the total computing power of honest nodes.

The more the forks are, the more the infighting among honest people’s blocks will be, the easier the malicious people’s attacks will be, and the less safe Bitcoin is. Thus for the sake of safety, Bitcoin is forced to maintain a low throughput rate.

Conflux adopts the DAG structure, which allows each block to reference multiple blocks as its parent blocks. This avoids the competition among honest people and therefore bypasses the dilemma faced by Bitcoin, enhancing the efficiency without compromising safety.

Ethereum is slightly more special than Bitcoin, which actually has the embryonic form of DAG structure. Those who have an interest in blockchain technology may be aware that, Ethereum contains the conception of ‘uncle block’, which, in Ethereum, is only meant for the system to provide consolation rewards to the blocks that end up not being included in the main chain.

Below is a graph that well demonstrates our advantage. It shows how the block utilization changes with different block generation intervals with 4-MB block size. Conflux conserves 100% block utilization under all generation intervals, whereas Bitcoin and Ghost (prototype of Ethereum Protocol) lose a lot of block utilization because of fork generation.

To summarize:

① Conflux is a PoW public chain similar to Bitcoin and Ethereum. However, it allows a block to have more than one parent blocks, therefore resulting in the formation of a DAG structure.

② The actual throughout rates of Bitcoin and Ethereum are very low. Even by shortening the block generation interval or increasing the block size, one cannot derive a public chain with both safety and efficiency.

③ In contrast to Bitcoin and Ethereum, Conflux is able to enhance the throughput rate without sacrificing either decentralization or safety.

Q2: DAG-based Smart contracts may encounter the “transaction order problem”. For example, whether a customer can successfully reserve a certain flight seat is affected by his/her transaction order. Was Conflux designed to address this problem?

Ming Wu: “Reserving a flight seat” is a very good example, from which we can see that, in the DAG, if different transactions have to compete for resources in the contract (for instance flight seats), block order and transaction order will become necessary. The orders will decide which transaction is in front, which is behind, and which can eventually gain the desired seat.

Just because of this, we need to design a topological sorting algorithm for the blocks in the DAG, which can come up with an order for all the blocks, and thereby decide the order of the transactions based on the block order. In addition, this topological sorting algorithm needs to meet the following requirements:

Consistency: The orders created by different miners need to be consistent with one another. It will lead to confusion if some miners inform you success in seat reservation, and some others inform you of the failure.

Safety (unmodifiable): the order should be unmodifiable by malicious people’s attack. For example, suppose you selected a seat, and 5 minutes later the reservation transaction was confirmed to be successful, and you were very happy. But 3 days later when you are ready for boarding, you find that the order has been modified and you already lost your seat. This will be regarded as a very serious public chain safety accident.

Conflux has designed a safe topological sorting algorithm that meets all the above requirements. Once input with a DAG, the algorithm is able to produce a topological order for all its blocks. When a miner (full node) applies this algorithm to the DAG on a local machine, he will derive the block order, according to which he will know the order of execution.

“Consistency” and “safety” might be relatively abstract. Let’s look at an example to help understand. Suppose that today we have 10,000 blocks in a DAG, among which the transactions in 9,900 blocks have been confirmed, and tomorrow, this same DAG turns to contain 20,000 blocks. Then if we apply the algorithm to both the DAG of today and the DAG of tomorrow, we should derive exactly the same order for the first 9,900 blocks, even under the double spend attack of malicious people. This is called “consistency” and “safety”.

The algorithm design of Conflux ensures both consistency and safety. If you are interested in the detailed design of this sorting algorithm, please refer to our assays and popular science articles for more information.

In conclusion, by designing a safe topological sorting algorithm, Conflux can perfectly solve the “transaction order problem”.

Q3: How do you solve the transaction conflict problem of packed transactions from different blocks? We understand that when a transaction conflict occurs, the later transactions need to be discarded. So what is your design to distinguish the transactions that are meant to be discarded?

Ming Wu: In Q2, we have solved the transaction order problem. Based on that, once all nodes have acquired a consistent order for the DAG blocks, one just has to follow one rule — when conflicts and duplicates occur, the transactions with posterior order should be discarded — to easily judge which transactions are invalid, and locally mark them. The consistency of the block order ensures that the “marking of invalid transactions” is also consistent.

Another point I would like to add here is, because the (in)validity of each transaction is judged by each miner himself without being permanently written in the block, it is impossible to prove the existence of a transaction in the block via Merkle Path as occurs in Bitcoin system. This is because, via Merkle Path, one cannot collect the information about whether the transaction in Conflux is valid or invalid. However, Conflux adopts the accounting model in which each block header saves the Hash value of the current ledger state. Through this Hash value, one can easily prove to light node things like the balance of specific addresses.

To summarize:

① The abandoned transactions will be marked locally by a full node. Consistency in the block order will ensure consistency in the marks.

② Based on point 1, the transactions in Conflux light nodes is confirmed in a somewhat different way than in the Bitcoin system.

Q4: Will the invalid transactions be marked by a specific status? Or in other words, when I check the Hash value of transactions in the block explorer, can I distinguish the valid and invalid transactions?

Ming Wu: The judgment of a transaction being invalid or not can be viewed as a result of the transaction execution, which can be recorded in the block. Therefore, one should be able to check the validity status of the transaction in the block explorer.

Q5: Will the result of the transaction execution be marked locally or on the blockchain?

Ming Wu: The mark will be saved locally, but it will also be reflected on the blockchain. In my previous answer, I have already mentioned that each blockhead would save the Hash value of the current ledger state. Therefore, the validity of each transaction in the history blocks can be reflected by the ledger state of blocks on the main chain.

Q6: Unlike other blockchains, an invalid transaction will not be recorded on the chains. Will the fact that Conflux needs to locally mark the invalid transactions bring extra learning costs to unfamiliar users? Will it be taken advantage of to confuse the users?

Ming Wu: the marks put on by the blockchain explorer will help normal users easily judge whether a transaction is valid or not.

Q7: The DAG structure does not have the “uncle block” problem. But will there be an excessive number of empty blocks or transaction duplicates in the network that cause data redundancy? This can put pressure on the network and hardware of the nodes.

Ming Wu: firstly, the generation of each block in the DAG consumes computing power. Therefore, the number of blocks in the network, whether normal or empty, will be restricted by the difficulty of mining and thus has an up limit. Therefore, no extra pressure will be created against the network and hardware.

Secondly, the existence of too many empty blocks and transaction duplicates will indeed affect the block utilization and the actual transaction throughput rate. We thus need to design a transaction selection algorithm for the miners to select transactions from the transaction pool in a weighted random fashion, with the transaction fee being a contributing factor. This will, to the maximal extent, avoid transaction duplicates. Importantly, the design of this algorithm needs to take incentive compatibility into consideration, so that the miners will be financially motivated to obey it.

Q8: Have you already finished the development of this algorithm?

Ming Wu: We have already finished the design and theoretical analysis, but the actual development of the algorithm is currently undergoing in our system, which is not finished yet.

Q9: Is the algorithm theoretically based on Prof. Yao’s new article?

Ming Wu: Prof. Yao’s new article mainly focused on the analysis of Bitcoin; however, it provided certain inspirations to our theoretical basis.

Q10: Will the project perform a premine? Will there be a change in how the miners are rewarded after Conflux is on the main net? Are block rewards on the pivot chains and on the fork chains the same?

Ming Wu: Just like in the Ethereum, in our system the genesis block allocates a certain fraction of tokens. The basic system reward in each block should be bountiful in the beginning, but will gradually decrease over time.

In Conflux, the system reward in each block is not a fixed value, but a variable calculated based on a certain rule. This rule applies to both blocks on the pivot chains and blocks on the fork chains.

(Editor’s note: before digging into more details on this rule, let’s consider the following situation: according to Conflux’s protocol, each newly generated block should select some reference edges, in order to allow all the pre-existing blocks to become its ancestors (please refer to our article for more details on the edge selecting rules). However, a malicious person may purposely ignore some pre-existing blocks when generating a new block, in order to earn more transaction fee or for some other reasons. In order to punish this kind of actions, we set the following rule — the more blocks one ignores, the less reward he will receive from this block.)

To describe this rule more specifically, I need to first introduce a concept named anticone-block. What exactly is anticone-block? In a DAG, if there is no path between two blocks, then these two blocks will be each other’s anticone-block. For example, in the graph below, Blocks B and C are each other’s anticone-block.

A block’s block reward is determined by both the base block reward and also the number of its own anticone-blocks. The more the anticone-blocks, the less its block reward. (Editor’s note: When a malicious person generates a new block, all the blocks he purposely ignores will become the anticone-blocks of the new block) This design will motivate miners to follow the protocol of reference edge selection.

Q11: How large is the fraction of the project’s premine? Also, can you tell us the rule of block number reduction in your system (for example, the block number in Bitcoin is reduced by half every 4 years)?

Ming Wu: These detailed data will be announced to the public before Conflux launched the main net. Please subscribe to our public account to receive first-hand information.

Q12: Because this design will end up making the reward of each block different. In that case, will there be uncertainty in the number of the coins? Will the uncertainty of each block’s reward results in over-mining in the first year?

Ming Wu: Although this design will make the reward of each block different, normally this difference won’t be large. We just wish to use this difference as a motivation for the miners to obey the protocol.

Q13: Approximately when will Conlux be put on the main net? How high can its TPS reach?

Ming Wu: We plan to launch the test net in March next year, and on the main network in the 3rd or 4th quarter of next year.

Editor: In this online Q&A program, we noticed that many audiences interested in blockchain expressed strong attention to incentive mechanisms and mining rules. In response to that, we will soon publish a special article covering these topics. If you are interested, please subscribe to our official account to stay informed at any time.