Dexon Code Review – sounds like an oil company, but no! Surprise, it’s the ‘premier blockchain platform for developing dApps’. Might be news to a few other platforms, but sure, let’s go with that.
By the way, Dapps? dApps? DApps? D’apps? (I made the last one up, but again, why not?) I think we should all just agree to call them supercallifragilisticdistributedapplications and be done with it.
So what’s the pitch: “DApps mass adoption is made possible with DEXON’s infinitely scalable, low-latency, and energy-efficient blocklattice technology.”
Infinitely scalable. Why are people still using this term? There is no such thing. We don’t even know if the universe is infinite, or inflationary.
Overly simplified, Dexon is a transaction DAG with broadcast BFT. This 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.
We start with simulation and simulation config.
Total order voted on, (I’m assuming voted, I haven’t seen the code yet).
Validator, not yet sure how elected or setup.
Consensus needs awareness of the governance, db, and network overlay.
This is our entry point. We setup a validator list and a network model.
Each node is a validator?
Servers that maintain a peer list.
For now, let’s look at 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 is a validator.
NewTCPNetwork, local = true, peerServer = cfg, model = NormalNetwork?
http communication,
Broadcast out a block to all known validators
Broadcast vote to all known validators. This is done synchronously, could gain some speed by going async.
Using protobuff for blocks. ETH crypto libraries. Leveldb.
Prepare / ACK / Commit, standard BFT?
Yeah, standard BFT.
Chain compacting built in, using same broadcast BFT to choose, it’s cool.
Leader selection built in.
Reliable broadcast, using same lattice structure for block ACK’s.
Dexon Code Review Conclusion:
So, it’s good code (even if it is a simulation), well developed, neatly written, great documentation. Easy to follow. But, it’s just another DAG with validator BFT. All validators have to be known. Some cool things in here, I like reliable broadcast, I like total ordering, I like the way they pushed BFT into the agreement state. It’s cool. But, it’s just another BlockDAG BFT.
Validators can vote semi independently and send their ack’s into their lattice and then share this lattice continuously.
How are they getting infinite scalability or even sub second finality, I don’t know, as this network grows that will change, or the validators must remain constant. You can’t have both. You can scale with node participation, but then propagation takes longer (even with BFT), or you can keep a low validator subset and low finality, but then you can’t scale “infinitely”.
The network size vs throughput argument remains. Do you send out 100 small blocks and have 100 nodes need to confirm them? Or do you send out 1 big block and have 100 nodes confirm it?
The one has a lot higher network overhead with messages being transmitted between nodes. And thus far we have no comparative tests to even see the throughput and finality difference.
You can chat about Dexon in our Telegram group.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
Dexon Code Review Timestamp: November 18th 2018
Comentários