Dexon Code Review: looks like an oil company, but no! Surprise, is the "main platform blockchain for the development of dApps". It could be news of a few other platforms, but of course, let's go with that.
By the way, Dapps? dApps? DApps? D & # 39; applications? (I did the last, but again, why not?) I think we should all agree on defining supercallifragilistic and redistributed applications.
So, what's the point: "The DApps mass adoption is made possible by the infinitely scalable, low-latency and efficient technology of the energy block".
Infinitely scalable. Why do people still use this term? There is nothing like it. We do not even know if the universe is infinite or inflationary.
Extremely simplified, Dexon is a transactional DAG with BFT transmission. It works when you have a small set of BFT nodes and all are known.
Dexon provided us with their simulation code, let's have a look.
Let's start with simulation and simulation configuration.
Total order voted, (I assume voted, I have not seen the code yet).
Validator, not yet sure how he was elected or configured.
The consent requires awareness of the governance, the db and the network overlay.
This is our starting point. We set up a list of validators and a network model.
Is every node a validator?
Servers that maintain an even list.
For now, let's take a look at the localTCP simulation.
Create a list of NewTCPNetwork (with a specified PeerServer), true, PeerServer, networkModel, start the network and add a new validator. All participants in this simulation are a validator.
NewTCPNetwork, local = true, peerServer = cfg, model = NormalNetwork?
Transmitted a block to all known validators
Pass the vote to all known validators. This is done synchronously, it could gain some speed by going asynchronously.
Use the protobuff for blocks. ETH cryptographic libraries. LevelDB.
Prepare / ACK / commit, BFT standard?
Yes, BFT standard.
Compacting the integrated chain, using the same BFT broadcast to choose from, is fantastic.
Selection of the integrated leader.
Reliable transmission, using the same reticular structure for block ACKs.
Conclusion of the Dexon code:
So, it's a good code (even if it's a simulation), well developed, well written, excellent documentation. Easy to follow. But it's just another DAG with BFT validator. All validators must be known. Some interesting things here, I like reliable transmission, I like total ordering, I like the way they pushed BFT into the state of the agreement. It's beautiful But it's just another BFT BlockDAG.
Validators can vote semi-independently and send their ack in their lattice and then share this grid continuously.
How they are achieving infinite scalability or even a second finality, I do not know, because this network will grow and change, or the validators must remain constant. You can not have both. It is possible to resize with the participation of the node, but propagation requires more time (even with BFT), or it is possible to keep a subset of low and low end validators, but it is not possible to resize "infinitely".
The topic of network size and actual speed remains. Send 100 small blocks and 100 knots have to confirm them? Or do you send 1 large block and 100 knots confirm it?
That has a much higher network overload with the messages transmitted between the nodes. And so far we have no comparative tests to see also the throughput and the difference in purpose.
You can chat on Dexon in our Telegram group.
disavowal: Crypto Briefing code revisions are performed by checking what is visible in the main branch of the repository made available. This was performed as an educational review and any commentary in the article is the writer's opinion. It's normal for the code to change quickly, so we'll chronologically record code revisions so that they show a snapshot at a particular time. The information contained in this document should not be used as comments or advice on the project as a whole.
Date / time of revision of the Dexon code: 18 November 2018